markdown conformance

README.md

@@ -1,29 +1,28 @@
-Unity Test ![CI](https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg)
+# Unity Test ![CI](https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg)
-==========
+
 __Copyright (c) 2007 - 2021 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
 
-Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org. Unity Test is a 
+Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org. Unity Test is a
-unit testing framework built for C, with a focus on working with embedded toolchains. 
+unit testing framework built for C, with a focus on working with embedded toolchains.
 
-This project is made to test code targetting microcontrollers big and small. The core project is a 
+This project is made to test code targetting microcontrollers big and small. The core project is a
-single C file and a pair of headers, allowing it to the added to your existing build setup without 
+single C file and a pair of headers, allowing it to the added to your existing build setup without
 too much headache. You may use any compiler you wish, and may use most existing build systems
-including make, cmake, etc. If you'd like to leave the hard work to us, you might be interested
+including Make, CMake, etc. If you'd like to leave the hard work to us, you might be interested
-in Ceedling, a build tool also by ThrowTheSwitch.org. 
+in Ceedling, a build tool also by ThrowTheSwitch.org.
 
 If you're new to Unity, we encourage you to tour the [getting started guide](docs/UnityGettingStartedGuide.md)
 
-Getting Started
+## Getting Started
-===============
+
-The [docs](docs/) folder contains a [getting started guide](docs/UnityGettingStartedGuide.md)
+The [docs](docs/) folder contains a [getting started guide](docs/UnityGettingStartedGuide.md)
-and much more tips about using Unity. 
+and much more tips about using Unity.
+
+## Unity Assertion Summary
 
-Unity Assertion Summary
-=======================
 For the full list, see [UnityAssertionsReference.md](docs/UnityAssertionsReference.md).
 
-Basic Validity Tests
+### Basic Validity Tests
---------------------
 
     TEST_ASSERT_TRUE(condition)
 
@@ -46,8 +45,7 @@ Another way of calling `TEST_ASSERT_FALSE`
 
 This test is automatically marked as a failure. The message is output stating why.
 
-Numerical Assertions: Integers
+### Numerical Assertions: Integers
-------------------------------
 
     TEST_ASSERT_EQUAL_INT(expected, actual)
     TEST_ASSERT_EQUAL_INT8(expected, actual)
@@ -87,19 +85,15 @@ Another way of calling TEST_ASSERT_EQUAL_INT
 Asserts that the actual value is within plus or minus delta of the expected value. This also comes in
 size specific variants.
 
-
     TEST_ASSERT_GREATER_THAN(threshold, actual)
 
 Asserts that the actual value is greater than the threshold. This also comes in size specific variants.
 
-
     TEST_ASSERT_LESS_THAN(threshold, actual)
 
 Asserts that the actual value is less than the threshold. This also comes in size specific variants.
 
-
+### Arrays
-Arrays
-------
 
     _ARRAY
 
@@ -116,8 +110,7 @@ value. You do this by specifying the EACH_EQUAL macro. For example:
 
     TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)
 
-Numerical Assertions: Bitwise
+### Numerical Assertions: Bitwise
------------------------------
 
     TEST_ASSERT_BITS(mask, expected, actual)
 
@@ -139,8 +132,7 @@ Test a single bit and verify that it is high.  The bit is specified 0-31 for a 3
 
 Test a single bit and verify that it is low.  The bit is specified 0-31 for a 32-bit integer.
 
-Numerical Assertions: Floats
+### Numerical Assertions: Floats
-----------------------------
 
     TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)
 
@@ -151,8 +143,7 @@ Asserts that the actual value is within plus or minus delta of the expected valu
 
 Asserts that two floating point values are "equal" within a small % delta of the expected value.
 
-String Assertions
+### String Assertions
------------------
 
     TEST_ASSERT_EQUAL_STRING(expected, actual)
 
@@ -170,8 +161,7 @@ Compare two null-terminate strings.  Fail if any character is different or if th
 
 Compare two strings. Fail if any character is different, stop comparing after len characters. Output a custom message on failure.
 
-Pointer Assertions
+### Pointer Assertions
-------------------
 
 Most pointer operations can be performed by simply using the integer comparisons above. However, a couple of special cases are added for clarity.
 
@@ -183,18 +173,15 @@ Fails if the pointer is not equal to NULL
 
 Fails if the pointer is equal to NULL
 
-Memory Assertions
+### Memory Assertions
------------------
 
     TEST_ASSERT_EQUAL_MEMORY(expected, actual, len)
 
 Compare two blocks of memory.  This is a good generic assertion for types that can't be coerced into acting like
 standard types... but since it's a memory compare, you have to be careful that your data types are packed.
 
-\_MESSAGE
+### \_MESSAGE
----------
 
-you can append \_MESSAGE to any of the macros to make them take an additional argument.  This argument
+you can append `\_MESSAGE` to any of the macros to make them take an additional argument.  This argument
 is a string that will be printed at the end of the failure strings.  This is useful for specifying more
 information about the problem.
-

docs/ThrowTheSwitchCodingStandard.md

@@ -8,14 +8,12 @@ and we'll try to be polite when we notice yours.
 
 ;)
 
-
 ## Why Have A Coding Standard?
 
 Being consistent makes code easier to understand. We've tried to keep
 our standard simple because we also believe that we can only expect someone to
 follow something that is understandable. Please do your best.
 
-
 ## Our Philosophy
 
 Before we get into details on syntax, let's take a moment to talk about our
@@ -46,7 +44,6 @@ default. We believe that if you're working with a simple compiler and target,
 you shouldn't need to configure very much... we try to make the tools guess as
 much as they can, but give the user the power to override it when it's wrong.
 
-
 ## Naming Things
 
 Let's talk about naming things. Programming is all about naming things. We name
@@ -56,20 +53,19 @@ finding *What Something WANTS to be Called*™.
 
 When naming things, we follow this hierarchy, the first being the
 most important to us (but we do all four when possible):
+
 1. Readable
 2. Descriptive
 3. Consistent
 4. Memorable
 
-
+### Readable
-#### Readable
 
 We want to read our code. This means we like names and flow that are more
 naturally read. We try to avoid double negatives. We try to avoid cryptic
 abbreviations (sticking to ones we feel are common).
 
-
+### Descriptive
-#### Descriptive
 
 We like descriptive names for things, especially functions and variables.
 Finding the right name for something is an important endeavor. You might notice
@@ -90,16 +86,14 @@ naming. We find i, j, and k are better loop counters than loopCounterVar or
 whatnot. We only break this rule when we see that more description could improve
 understanding of an algorithm.
 
-
+### Consistent
-#### Consistent
 
 We like consistency, but we're not really obsessed with it. We try to name our
 configuration macros in a consistent fashion... you'll notice a repeated use of
 UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
 remember each macro's details.
 
-
+### Memorable
-#### Memorable
 
 Where ever it doesn't violate the above principles, we try to apply memorable
 names. Sometimes this means using something that is simply descriptive, but
@@ -108,10 +102,9 @@ out in our memory and are easier to search for. Take a look through the file
 names in Ceedling and you'll get a good idea of what we are talking about here.
 Why use preprocess when you can use preprocessinator? Or what better describes a
 module in charge of invoking tasks during releases than release_invoker? Don't
-get carried away. The names are still descriptive and fulfill the above
+get carried away. The names are still descriptive and fulfil the above
 requirements, but they don't feel stale.
 
-
 ## C and C++ Details
 
 We don't really want to add to the style battles out there. Tabs or spaces?
@@ -123,8 +116,7 @@ We've decided on our own style preferences. If you'd like to contribute to these
 projects (and we hope that you do), then we ask if you do your best to follow
 the same. It will only hurt a little. We promise.
 
-
+### Whitespace in C/C++
-#### Whitespace
 
 Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
 power-of-2 number that looks decent on a wide-screen. We have no more reason
@@ -139,8 +131,7 @@ things up in nice tidy columns.
     }
 ```
 
-
+### Case in C/C++
-#### Case
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -149,8 +140,7 @@ things up in nice tidy columns.
 - Functions - camel cased. Usually named ModuleName_FuncName
 - Constants and Globals - camel cased.
 
-
+### Braces in C/C++
-#### Braces
 
 The left brace is on the next line after the declaration. The right brace is
 directly below that. Everything in between in indented one level. If you're
@@ -163,8 +153,7 @@ catching an error and you have a one-line, go ahead and to it on the same line.
     }
 ```
 
-
+### Comments in C/C++
-#### Comments
 
 Do you know what we hate? Old-school C block comments. BUT, we're using them
 anyway. As we mentioned, our goal is to support every compiler we can,
@@ -172,23 +161,20 @@ especially embedded compilers. There are STILL C compilers out there that only
 support old-school block comments. So that is what we're using. We apologize. We
 think they are ugly too.
 
-
 ## Ruby Details
 
 Is there really such thing as a Ruby coding standard? Ruby is such a free form
 language, it seems almost sacrilegious to suggest that people should comply to
 one method! We'll keep it really brief!
 
-
+### Whitespace in Ruby
-#### Whitespace
 
 Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
 nice power-of-2 number that really grooves with Ruby's compact style. We have no
 more reason than that. We break that rule when we have lines that wrap. When
 that happens, we like to indent further to line things up in nice tidy columns.
 
-
+### Case in Ruby
-#### Case
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -196,11 +182,9 @@ that happens, we like to indent further to line things up in nice tidy columns.
 - Functions - all lower case with underscores
 - Constants - all upper case with underscores
 
-
 ## Documentation
 
 Egad. Really? We use mark down and we like pdf files because they can be made to
 look nice while still being portable. Good enough?
 
-
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

docs/UnityAssertionsReference.md

@@ -16,7 +16,6 @@ source code in, well, test code.
 - Document types, expected values, and basic behavior in your source code for
 free.
 
-
 ### Unity Is Several Things But Mainly It's Assertions
 
 One way to think of Unity is simply as a rich collection of assertions you can
@@ -24,7 +23,6 @@ use to establish whether your source code behaves the way you think it does.
 Unity provides a framework to easily organize and execute those assertions in
 test code separate from your source code.
 
-
 ### What's an Assertion?
 
 At their core, assertions are an establishment of truth - boolean truth. Was this
@@ -44,7 +42,6 @@ support, it's far too tempting to litter source code with C's `assert()`'s. It's
 generally much cleaner, manageable, and more useful to separate test and source
 code in the way Unity facilitates.
 
-
 ### Unity's Assertions: Helpful Messages _and_ Free Source Code Documentation
 
 Asserting a simple truth condition is valuable, but using the context of the
@@ -60,34 +57,32 @@ tests pass, you have a detailed, up-to-date view of the intent and mechanisms in
 your source code. And due to a wondrous mystery, well-tested code usually tends
 to be well designed code.
 
-
 ## Assertion Conventions and Configurations
 
 ### Naming and Parameter Conventions
 
 The convention of assertion parameters generally follows this order:
 
-```
+```c
 TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
 ```
 
 The very simplest assertion possible uses only a single `actual` parameter (e.g.
 a simple null check).
 
- - `Actual` is the value being tested and unlike the other parameters in an
+- `Actual` is the value being tested and unlike the other parameters in an
-    assertion construction is the only parameter present in all assertion variants.
+  assertion construction is the only parameter present in all assertion variants.
- - `Modifiers` are masks, ranges, bit flag specifiers, floating point deltas.
+- `Modifiers` are masks, ranges, bit flag specifiers, floating point deltas.
- - `Expected` is your expected value (duh) to compare to an `actual` value; it's
+- `Expected` is your expected value (duh) to compare to an `actual` value; it's
-    marked as an optional parameter because some assertions only need a single
+  marked as an optional parameter because some assertions only need a single
-    `actual` parameter (e.g. null check).
+  `actual` parameter (e.g. null check).
- - `Size/count` refers to string lengths, number of array elements, etc.
+- `Size/count` refers to string lengths, number of array elements, etc.
 
 Many of Unity's assertions are clear duplications in that the same data type
 is handled by several assertions. The differences among these are in how failure
 messages are presented. For instance, a `_HEX` variant of an assertion prints
 the expected and actual values of that assertion formatted as hexadecimal.
 
-
 #### TEST_ASSERT_X_MESSAGE Variants
 
 _All_ assertions are complemented with a variant that includes a simple string
@@ -100,17 +95,18 @@ the reference list below and add a string as the final parameter.
 
 _Example:_
 
-```
+```c
 TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
 ```
 
 becomes messageified like thus...
 
-```
+```c
 TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )
 ```
 
 Notes:
+
 - The `_MESSAGE` variants intentionally do not support `printf` style formatting
   since many embedded projects don't support or avoid `printf` for various reasons.
   It is possible to use `sprintf` before the assertion to assemble a complex fail
@@ -119,7 +115,6 @@ Notes:
   a loop) , building up an array of results and then using one of the `_ARRAY`
   assertions (see below) might be a handy alternative to `sprintf`.
 
-
 #### TEST_ASSERT_X_ARRAY Variants
 
 Unity provides a collection of assertions for arrays containing a variety of
@@ -128,22 +123,21 @@ with the `_MESSAGE`variants of Unity's Asserts in that for pretty much any Unity
 type assertion you can tack on `_ARRAY` and run assertions on an entire block of
 memory.
 
-```
+```c
     TEST_ASSERT_EQUAL_TYPEX_ARRAY( expected, actual, {size/count} )
 ```
 
- - `Expected` is an array itself.
+- `Expected` is an array itself.
- - `Size/count` is one or two parameters necessary to establish the number of array
+- `Size/count` is one or two parameters necessary to establish the number of array
-    elements and perhaps the length of elements within the array.
+  elements and perhaps the length of elements within the array.
 
 Notes:
 
- - The `_MESSAGE` variant convention still applies here to array assertions. The
+- The `_MESSAGE` variant convention still applies here to array assertions. The
-   `_MESSAGE` variants of the `_ARRAY` assertions have names ending with
+  `_MESSAGE` variants of the `_ARRAY` assertions have names ending with
-   `_ARRAY_MESSAGE`.
+  `_ARRAY_MESSAGE`.
- - Assertions for handling arrays of floating point values are grouped with float
+- Assertions for handling arrays of floating point values are grouped with float
-   and double assertions (see immediately following section).
+  and double assertions (see immediately following section).
-
 
 ### TEST_ASSERT_EACH_EQUAL_X Variants
 
@@ -153,21 +147,20 @@ the Each Equal section below. these are almost on par with the `_MESSAGE`
 variants of Unity's Asserts in that for pretty much any Unity type assertion you
 can inject `_EACH_EQUAL` and run assertions on an entire block of memory.
 
-```
+```c
 TEST_ASSERT_EACH_EQUAL_TYPEX( expected, actual, {size/count} )
 ```
 
- - `Expected` is a single value to compare to.
+- `Expected` is a single value to compare to.
- - `Actual` is an array where each element will be compared to the expected value.
+- `Actual` is an array where each element will be compared to the expected value.
- - `Size/count` is one of two parameters necessary to establish the number of array
+- `Size/count` is one of two parameters necessary to establish the number of array
-    elements and perhaps the length of elements within the array.
+  elements and perhaps the length of elements within the array.
 
 Notes:
 
- - The `_MESSAGE` variant convention still applies here to Each Equal assertions.
+- The `_MESSAGE` variant convention still applies here to Each Equal assertions.
- - Assertions for handling Each Equal of floating point values are grouped with
+- Assertions for handling Each Equal of floating point values are grouped with
-   float and double assertions (see immediately following section).
+  float and double assertions (see immediately following section).
-
 
 ### Configuration
 
@@ -179,7 +172,6 @@ or disabled in Unity code. This is useful for embedded targets with no floating
 point math support (i.e. Unity compiles free of errors for fixed point only
 platforms). See Unity documentation for specifics.
 
-
 #### Maximum Data Type Width Is Configurable
 
 Not all targets support 64 bit wide types or even 32 bit wide types. Define the
@@ -187,14 +179,13 @@ appropriate preprocessor symbols and Unity will omit all operations from
 compilation that exceed the maximum width of your target. See Unity
 documentation for specifics.
 
-
 ## The Assertions in All Their Blessed Glory
 
 ### Basic Fail, Pass and Ignore
 
-##### `TEST_FAIL()`
+#### `TEST_FAIL()`
 
-##### `TEST_FAIL_MESSAGE("message")`
+#### `TEST_FAIL_MESSAGE("message")`
 
 This fella is most often used in special conditions where your test code is
 performing logic beyond a simple assertion. That is, in practice, `TEST_FAIL()`
@@ -207,25 +198,25 @@ code then verifies as a final step.
 - Triggering an exception and verifying it (as in Try / Catch / Throw - see the
 [CException](https://github.com/ThrowTheSwitch/CException) project).
 
-##### `TEST_PASS()`
+#### `TEST_PASS()`
 
-##### `TEST_PASS_MESSAGE("message")`
+#### `TEST_PASS_MESSAGE("message")`
 
 This will abort the remainder of the test, but count the test as a pass. Under
 normal circumstances, it is not necessary to include this macro in your tests...
 a lack of failure will automatically be counted as a `PASS`. It is occasionally
 useful for tests with `#ifdef`s and such.
 
-##### `TEST_IGNORE()`
+#### `TEST_IGNORE()`
 
-##### `TEST_IGNORE_MESSAGE("message")`
+#### `TEST_IGNORE_MESSAGE("message")`
 
 Marks a test case (i.e. function meant to contain test assertions) as ignored.
 Usually this is employed as a breadcrumb to come back and implement a test case.
 An ignored test case has effects if other assertions are in the enclosing test
 case (see Unity documentation for more).
 
-##### `TEST_MESSAGE(message)`
+#### `TEST_MESSAGE(message)`
 
 This can be useful for outputting `INFO` messages into the Unity output stream
 without actually ending the test. Like pass and fail messages, it will be output
@@ -233,27 +224,27 @@ with the filename and line number.
 
 ### Boolean
 
-##### `TEST_ASSERT (condition)`
+#### `TEST_ASSERT (condition)`
 
-##### `TEST_ASSERT_TRUE (condition)`
+#### `TEST_ASSERT_TRUE (condition)`
 
-##### `TEST_ASSERT_FALSE (condition)`
+#### `TEST_ASSERT_FALSE (condition)`
 
-##### `TEST_ASSERT_UNLESS (condition)`
+#### `TEST_ASSERT_UNLESS (condition)`
 
 A simple wording variation on `TEST_ASSERT_FALSE`.The semantics of
 `TEST_ASSERT_UNLESS` aid readability in certain test constructions or
 conditional statements.
 
-##### `TEST_ASSERT_NULL (pointer)`
+#### `TEST_ASSERT_NULL (pointer)`
 
-##### `TEST_ASSERT_NOT_NULL (pointer)`
+#### `TEST_ASSERT_NOT_NULL (pointer)`
 
 Verify if a pointer is or is not NULL.
 
-##### `TEST_ASSERT_EMPTY (pointer)`
+#### `TEST_ASSERT_EMPTY (pointer)`
 
-##### `TEST_ASSERT_NOT_EMPTY (pointer)`
+#### `TEST_ASSERT_NOT_EMPTY (pointer)`
 
 Verify if the first element dereferenced from a pointer is or is not zero. This
 is particularly useful for checking for empty (or non-empty) null-terminated
@@ -268,26 +259,25 @@ that would break compilation (see Unity documentation for more). Refer to
 Advanced Asserting later in this document for advice on dealing with other word
 sizes.
 
-##### `TEST_ASSERT_EQUAL_INT (expected, actual)`
+#### `TEST_ASSERT_EQUAL_INT (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_INT8 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_INT8 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_INT16 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_INT16 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_INT32 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_INT32 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_INT64 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_INT64 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_UINT (expected, actual)`
+#### `TEST_ASSERT_EQUAL_UINT (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_UINT8 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_UINT8 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_UINT16 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_UINT16 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_UINT32 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_UINT32 (expected, actual)`
-
-##### `TEST_ASSERT_EQUAL_UINT64 (expected, actual)`
 
+#### `TEST_ASSERT_EQUAL_UINT64 (expected, actual)`
 
 ### Unsigned Integers (of all sizes) in Hexadecimal
 
@@ -295,16 +285,15 @@ All `_HEX` assertions are identical in function to unsigned integer assertions
 but produce failure messages with the `expected` and `actual` values formatted
 in hexadecimal. Unity output is big endian.
 
-##### `TEST_ASSERT_EQUAL_HEX (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
-
-##### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
 
+#### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
 
 ### Characters
 
@@ -312,36 +301,30 @@ While you can use the 8-bit integer assertions to compare `char`, another option
 to use this specialized assertion which will show printable characters as printables,
 otherwise showing the HEX escape code for the characters.
 
-##### `TEST_ASSERT_EQUAL_CHAR (expected, actual)`
+#### `TEST_ASSERT_EQUAL_CHAR (expected, actual)`
-
 
 ### Masked and Bit-level Assertions
 
 Masked and bit-level assertions produce output formatted in hexadecimal. Unity
 output is big endian.
 
-
+#### `TEST_ASSERT_BITS (mask, expected, actual)`
-##### `TEST_ASSERT_BITS (mask, expected, actual)`
 
 Only compares the masked (i.e. high) bits of `expected` and `actual` parameters.
 
-
+#### `TEST_ASSERT_BITS_HIGH (mask, actual)`
-##### `TEST_ASSERT_BITS_HIGH (mask, actual)`
 
 Asserts the masked bits of the `actual` parameter are high.
 
-
+#### `TEST_ASSERT_BITS_LOW (mask, actual)`
-##### `TEST_ASSERT_BITS_LOW (mask, actual)`
 
 Asserts the masked bits of the `actual` parameter are low.
 
-
+#### `TEST_ASSERT_BIT_HIGH (bit, actual)`
-##### `TEST_ASSERT_BIT_HIGH (bit, actual)`
 
 Asserts the specified bit of the `actual` parameter is high.
 
-
+#### `TEST_ASSERT_BIT_LOW (bit, actual)`
-##### `TEST_ASSERT_BIT_LOW (bit, actual)`
 
 Asserts the specified bit of the `actual` parameter is low.
 
@@ -352,16 +335,15 @@ than `threshold` (exclusive). For example, if the threshold value is 0 for the
 greater than assertion will fail if it is 0 or less. There are assertions for
 all the various sizes of ints, as for the equality assertions. Some examples:
 
-##### `TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`
+#### `TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`
 
-##### `TEST_ASSERT_GREATER_OR_EQUAL_INT16 (threshold, actual)`
+#### `TEST_ASSERT_GREATER_OR_EQUAL_INT16 (threshold, actual)`
 
-##### `TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`
+#### `TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`
 
-##### `TEST_ASSERT_LESS_OR_EQUAL_UINT (threshold, actual)`
+#### `TEST_ASSERT_LESS_OR_EQUAL_UINT (threshold, actual)`
-
-##### `TEST_ASSERT_NOT_EQUAL_UINT8 (threshold, actual)`
 
+#### `TEST_ASSERT_NOT_EQUAL_UINT8 (threshold, actual)`
 
 ### Integer Ranges (of all sizes)
 
@@ -370,60 +352,57 @@ These assertions verify that the `expected` parameter is within +/- `delta`
 and the delta is 3 then the assertion will fail for any value outside the range
 of 7 - 13.
 
-##### `TEST_ASSERT_INT_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_INT_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`
 
-##### `TEST_ASSERT_CHAR_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_CHAR_WITHIN (delta, expected, actual)`
 
 ### Structs and Strings
 
-##### `TEST_ASSERT_EQUAL_PTR (expected, actual)`
+#### `TEST_ASSERT_EQUAL_PTR (expected, actual)`
 
 Asserts that the pointers point to the same memory location.
 
-
+#### `TEST_ASSERT_EQUAL_STRING (expected, actual)`
-##### `TEST_ASSERT_EQUAL_STRING (expected, actual)`
 
 Asserts that the null terminated (`'\0'`)strings are identical. If strings are
 of different lengths or any portion of the strings before their terminators
 differ, the assertion fails. Two NULL strings (i.e. zero length) are considered
 equivalent.
 
-
+#### `TEST_ASSERT_EQUAL_MEMORY (expected, actual, len)`
-##### `TEST_ASSERT_EQUAL_MEMORY (expected, actual, len)`
 
 Asserts that the contents of the memory specified by the `expected` and `actual`
 pointers is identical. The size of the memory blocks in bytes is specified by
 the `len` parameter.
 
-
 ### Arrays
 
 `expected` and `actual` parameters are both arrays. `num_elements` specifies the
@@ -438,43 +417,43 @@ For array of strings comparison behavior, see comments for
 Assertions fail upon the first element in the compared arrays found not to
 match. Failure messages specify the array index of the failed comparison.
 
-##### `TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_CHAR_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_CHAR_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`
+#### `TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`
 
-##### `TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`
+#### `TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`
 
 `len` is the memory in bytes to be compared at each array element.
 
@@ -485,37 +464,37 @@ These assertions verify that the `expected` array parameter is within +/- `delta
 \[10, 12\] and the delta is 3 then the assertion will fail for any value
 outside the range of \[7 - 13, 9 - 15\].
 
-##### `TEST_ASSERT_INT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_INT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_INT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_INT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_INT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_INT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_INT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_INT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_INT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_INT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_UINT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_UINT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_UINT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_UINT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_UINT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_UINT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_UINT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_UINT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_UINT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_UINT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_HEX_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_HEX_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_HEX8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_HEX8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_HEX16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_HEX16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_HEX32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_HEX32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_HEX64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_HEX64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
-##### `TEST_ASSERT_CHAR_ARRAY_WITHIN (delta, expected, actual, num_elements)`
+#### `TEST_ASSERT_CHAR_ARRAY_WITHIN (delta, expected, actual, num_elements)`
 
 ### Each Equal (Arrays to Single Value)
 
@@ -568,17 +547,15 @@ match. Failure messages specify the array index of the failed comparison.
 
 `len` is the memory in bytes to be compared at each array element.
 
-
 ### Floating Point (If enabled)
 
-##### `TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`
 
 Asserts that the `actual` value is within +/- `delta` of the `expected` value.
 The nature of floating point representation is such that exact evaluations of
 equality are not guaranteed.
 
-
+#### `TEST_ASSERT_EQUAL_FLOAT (expected, actual)`
-##### `TEST_ASSERT_EQUAL_FLOAT (expected, actual)`
 
 Asserts that the ?actual?value is "close enough to be considered equal" to the
 `expected` value. If you are curious about the details, refer to the Advanced
@@ -586,74 +563,63 @@ Asserting section for more details on this. Omitting a user-specified delta in a
 floating point assertion is both a shorthand convenience and a requirement of
 code generation conventions for CMock.
 
-
+#### `TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`
-##### `TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`
 
 See Array assertion section for details. Note that individual array element
 float comparisons are executed using T?EST_ASSERT_EQUAL_FLOAT?.That is, user
 specified delta comparison values requires a custom-implemented floating point
 array assertion.
 
-
+#### `TEST_ASSERT_FLOAT_IS_INF (actual)`
-##### `TEST_ASSERT_FLOAT_IS_INF (actual)`
 
 Asserts that `actual` parameter is equivalent to positive infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`
-##### `TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`
 
 Asserts that `actual` parameter is equivalent to negative infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_FLOAT_IS_NAN (actual)`
-##### `TEST_ASSERT_FLOAT_IS_NAN (actual)`
 
 Asserts that `actual` parameter is a Not A Number floating point representation.
 
-
+#### `TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`
-##### `TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`
 
 Asserts that ?actual?parameter is a floating point representation usable for
 mathematical operations. That is, the `actual` parameter is neither positive
 infinity nor negative infinity nor Not A Number floating point representations.
 
-
+#### `TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`
-##### `TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`
 
 Asserts that `actual` parameter is a value other than positive infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`
-##### `TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`
 
 Asserts that `actual` parameter is a value other than negative infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`
-##### `TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`
 
 Asserts that `actual` parameter is a value other than Not A Number floating
 point representation.
 
-
+#### `TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`
-##### `TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`
 
 Asserts that `actual` parameter is not usable for mathematical operations. That
 is, the `actual` parameter is either positive infinity or negative infinity or
 Not A Number floating point representations.
 
-
 ### Double (If enabled)
 
-##### `TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`
+#### `TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`
 
 Asserts that the `actual` value is within +/- `delta` of the `expected` value.
 The nature of floating point representation is such that exact evaluations of
 equality are not guaranteed.
 
-
+#### `TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`
-##### `TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`
 
 Asserts that the `actual` value is "close enough to be considered equal" to the
 `expected` value. If you are curious about the details, refer to the Advanced
@@ -661,64 +627,54 @@ Asserting section for more details. Omitting a user-specified delta in a
 floating point assertion is both a shorthand convenience and a requirement of
 code generation conventions for CMock.
 
-
+#### `TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`
-##### `TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`
 
 See Array assertion section for details. Note that individual array element
 double comparisons are executed using `TEST_ASSERT_EQUAL_DOUBLE`.That is, user
 specified delta comparison values requires a custom implemented double array
 assertion.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_INF (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_INF (actual)`
 
 Asserts that `actual` parameter is equivalent to positive infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`
 
 Asserts that `actual` parameter is equivalent to negative infinity floating point
 representation.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_NAN (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_NAN (actual)`
 
 Asserts that `actual` parameter is a Not A Number floating point representation.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`
 
 Asserts that `actual` parameter is a floating point representation usable for
 mathematical operations. That is, the ?actual?parameter is neither positive
 infinity nor negative infinity nor Not A Number floating point representations.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`
 
 Asserts that `actual` parameter is a value other than positive infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`
 
 Asserts that `actual` parameter is a value other than negative infinity floating
 point representation.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`
 
 Asserts that `actual` parameter is a value other than Not A Number floating
 point representation.
 
-
+#### `TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`
-##### `TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`
 
 Asserts that `actual` parameter is not usable for mathematical operations. That
 is, the `actual` parameter is either positive infinity or negative infinity or
 Not A Number floating point representations.
 
-
 ## Advanced Asserting: Details On Tricky Assertions
 
 This section helps you understand how to deal with some of the trickier
@@ -727,7 +683,6 @@ the under-the-hood details of Unity's assertion mechanisms. If you're one of
 those people who likes to know what is going on in the background, read on. If
 not, feel free to ignore the rest of this document until you need it.
 
-
 ### How do the EQUAL assertions work for FLOAT and DOUBLE?
 
 As you may know, directly checking for equality between a pair of floats or a
@@ -768,7 +723,6 @@ assertions less strict, you can change these multipliers to whatever you like by
 defining UNITY_FLOAT_PRECISION and UNITY_DOUBLE_PRECISION. See Unity
 documentation for more.
 
-
 ### How do we deal with targets with non-standard int sizes?
 
 It's "fun" that C is a standard where something as fundamental as an integer
@@ -827,5 +781,4 @@ operations, particularly `TEST_ASSERT_INT_WITHIN`.Such assertions might wrap
 your `int` in the wrong place, and you could experience false failures. You can
 always back down to a simple `TEST_ASSERT` and do the operations yourself.
 
-
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

docs/UnityConfigurationGuide.md

@@ -22,7 +22,6 @@ challenging to build. From a more positive perspective, it is also proof that a
 great deal of complexity can be centralized primarily to one place to
 provide a more consistent and simple experience elsewhere.
 
-
 ### Using These Options
 
 It doesn't matter if you're using a target-specific compiler and a simulator or
@@ -58,8 +57,7 @@ certainly not every compiler you are likely to encounter. Therefore, Unity has a
 number of features for helping to adjust itself to match your required integer
 sizes. It starts off by trying to do it automatically.
 
-
+#### `UNITY_EXCLUDE_STDINT_H`
-##### `UNITY_EXCLUDE_STDINT_H`
 
 The first thing that Unity does to guess your types is check `stdint.h`.
 This file includes defines like `UINT_MAX` that Unity can use to
@@ -70,18 +68,19 @@ That way, Unity will know to skip the inclusion of this file and you won't
 be left with a compiler error.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_STDINT_H
 ```
 
-
+#### `UNITY_EXCLUDE_LIMITS_H`
-##### `UNITY_EXCLUDE_LIMITS_H`
 
 The second attempt to guess your types is to check `limits.h`. Some compilers
 that don't support `stdint.h` could include `limits.h` instead. If you don't
 want Unity to check this file either, define this to make it skip the inclusion.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_LIMITS_H
 ```
@@ -91,19 +90,18 @@ do the configuration yourself. Don't worry. Even this isn't too bad... there are
 just a handful of defines that you are going to specify if you don't like the
 defaults.
 
-
+#### `UNITY_INT_WIDTH`
-##### `UNITY_INT_WIDTH`
 
 Define this to be the number of bits an `int` takes up on your system. The
 default, if not autodetected, is 32 bits.
 
 _Example:_
+
 ```C
 #define UNITY_INT_WIDTH 16
 ```
 
-
+#### `UNITY_LONG_WIDTH`
-##### `UNITY_LONG_WIDTH`
 
 Define this to be the number of bits a `long` takes up on your system. The
 default, if not autodetected, is 32 bits. This is used to figure out what kind
@@ -112,12 +110,12 @@ of 64-bit support your system can handle. Does it need to specify a `long` or a
 ignored.
 
 _Example:_
+
 ```C
 #define UNITY_LONG_WIDTH 16
 ```
 
-
+#### `UNITY_POINTER_WIDTH`
-##### `UNITY_POINTER_WIDTH`
 
 Define this to be the number of bits a pointer takes up on your system. The
 default, if not autodetected, is 32-bits. If you're getting ugly compiler
@@ -129,6 +127,7 @@ width of 23-bit), choose the next power of two (in this case 32-bit).
 _Supported values:_ 16, 32 and 64
 
 _Example:_
+
 ```C
 // Choose on of these #defines to set your pointer width (if not autodetected)
 //#define UNITY_POINTER_WIDTH 16
@@ -136,8 +135,7 @@ _Example:_
 #define UNITY_POINTER_WIDTH 64 // Set UNITY_POINTER_WIDTH to 64-bit
 ```
 
-
+#### `UNITY_SUPPORT_64`
-##### `UNITY_SUPPORT_64`
 
 Unity will automatically include 64-bit support if it auto-detects it, or if
 your `int`, `long`, or pointer widths are greater than 32-bits. Define this to
@@ -146,11 +144,11 @@ can be a significant size and speed impact to enabling 64-bit support on small
 targets, so don't define it if you don't need it.
 
 _Example:_
+
 ```C
 #define UNITY_SUPPORT_64
 ```
 
-
 ### Floating Point Types
 
 In the embedded world, it's not uncommon for targets to have no support for
@@ -160,14 +158,13 @@ are always available in at least one size. Floating point, on the other hand, is
 sometimes not available at all. Trying to include `float.h` on these platforms
 would result in an error. This leaves manual configuration as the only option.
 
+#### `UNITY_INCLUDE_FLOAT`
 
-##### `UNITY_INCLUDE_FLOAT`
+#### `UNITY_EXCLUDE_FLOAT`
 
-##### `UNITY_EXCLUDE_FLOAT`
+#### `UNITY_INCLUDE_DOUBLE`
 
-##### `UNITY_INCLUDE_DOUBLE`
+#### `UNITY_EXCLUDE_DOUBLE`
-
-##### `UNITY_EXCLUDE_DOUBLE`
 
 By default, Unity guesses that you will want single precision floating point
 support, but not double precision. It's easy to change either of these using the
@@ -176,14 +173,14 @@ suits your needs. For features that are enabled, the following floating point
 options also become available.
 
 _Example:_
+
 ```C
 //what manner of strange processor is this?
 #define UNITY_EXCLUDE_FLOAT
 #define UNITY_INCLUDE_DOUBLE
 ```
 
-
+#### `UNITY_EXCLUDE_FLOAT_PRINT`
-##### `UNITY_EXCLUDE_FLOAT_PRINT`
 
 Unity aims for as small of a footprint as possible and avoids most standard
 library calls (some embedded platforms don’t have a standard library!). Because
@@ -196,24 +193,24 @@ can use this define to instead respond to a failed assertion with a message like
 point assertions, use these options to give more explicit failure messages.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_FLOAT_PRINT
 ```
 
-
+#### `UNITY_FLOAT_TYPE`
-##### `UNITY_FLOAT_TYPE`
 
 If enabled, Unity assumes you want your `FLOAT` asserts to compare standard C
 floats. If your compiler supports a specialty floating point type, you can
 always override this behavior by using this definition.
 
 _Example:_
+
 ```C
 #define UNITY_FLOAT_TYPE float16_t
 ```
 
-
+#### `UNITY_DOUBLE_TYPE`
-##### `UNITY_DOUBLE_TYPE`
 
 If enabled, Unity assumes you want your `DOUBLE` asserts to compare standard C
 doubles. If you would like to change this, you can specify something else by
@@ -222,14 +219,14 @@ could enable gargantuan floating point types on your 64-bit processor instead of
 the standard `double`.
 
 _Example:_
+
 ```C
 #define UNITY_DOUBLE_TYPE long double
 ```
 
+#### `UNITY_FLOAT_PRECISION`
 
-##### `UNITY_FLOAT_PRECISION`
+#### `UNITY_DOUBLE_PRECISION`
-
-##### `UNITY_DOUBLE_PRECISION`
 
 If you look up `UNITY_ASSERT_EQUAL_FLOAT` and `UNITY_ASSERT_EQUAL_DOUBLE` as
 documented in the big daddy Unity Assertion Guide, you will learn that they are
@@ -243,14 +240,14 @@ For further details on how this works, see the appendix of the Unity Assertion
 Guide.
 
 _Example:_
+
 ```C
 #define UNITY_FLOAT_PRECISION 0.001f
 ```
 
-
 ### Miscellaneous
 
-##### `UNITY_EXCLUDE_STDDEF_H`
+#### `UNITY_EXCLUDE_STDDEF_H`
 
 Unity uses the `NULL` macro, which defines the value of a null pointer constant,
 defined in `stddef.h` by default. If you want to provide
@@ -258,11 +255,11 @@ your own macro for this, you should exclude the `stddef.h` header file by adding
 define to your configuration.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_STDDEF_H
 ```
 
-
 #### `UNITY_INCLUDE_PRINT_FORMATTED`
 
 Unity provides a simple (and very basic) printf-like string output implementation,
@@ -282,6 +279,7 @@ which is able to print a string modified by the following format string modifier
 - __%%__ - The "%" symbol (escaped)
 
 _Example:_
+
 ```C
 #define UNITY_INCLUDE_PRINT_FORMATTED
 
@@ -300,7 +298,6 @@ TEST_PRINTF("\n");
 TEST_PRINTF("Multiple (%d) (%i) (%u) (%x)\n", -100, 0, 200, 0x12345);
 ```
 
-
 ### Toolset Customization
 
 In addition to the options listed above, there are a number of other options
@@ -310,14 +307,13 @@ certain platforms, particularly those running in simulators, may need to jump
 through extra hoops to run properly. These macros will help in those
 situations.
 
+#### `UNITY_OUTPUT_CHAR(a)`
 
-##### `UNITY_OUTPUT_CHAR(a)`
+#### `UNITY_OUTPUT_FLUSH()`
 
-##### `UNITY_OUTPUT_FLUSH()`
+#### `UNITY_OUTPUT_START()`
 
-##### `UNITY_OUTPUT_START()`
+#### `UNITY_OUTPUT_COMPLETE()`
-
-##### `UNITY_OUTPUT_COMPLETE()`
 
 By default, Unity prints its results to `stdout` as it runs. This works
 perfectly fine in most situations where you are using a native compiler for
@@ -333,6 +329,7 @@ _Example:_
 Say you are forced to run your test suite on an embedded processor with no
 `stdout` option. You decide to route your test result output to a custom serial
 `RS232_putc()` function you wrote like thus:
+
 ```C
 #include "RS232_header.h"
 ...
@@ -346,44 +343,43 @@ _Note:_
 `UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by
 specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
 
+#### `UNITY_OUTPUT_FOR_ECLIPSE`
 
-##### `UNITY_OUTPUT_FOR_ECLIPSE`
+#### `UNITY_OUTPUT_FOR_IAR_WORKBENCH`
 
-##### `UNITY_OUTPUT_FOR_IAR_WORKBENCH`
+#### `UNITY_OUTPUT_FOR_QT_CREATOR`
-
-##### `UNITY_OUTPUT_FOR_QT_CREATOR`
 
 When managing your own builds, it is often handy to have messages output in a format which is
 recognized by your IDE. These are some standard formats which can be supported. If you're using
 Ceedling to manage your builds, it is better to stick with the standard format (leaving these
 all undefined) and allow Ceedling to use its own decorators.
 
-
+#### `UNITY_PTR_ATTRIBUTE`
-##### `UNITY_PTR_ATTRIBUTE`
 
 Some compilers require a custom attribute to be assigned to pointers, like
 `near` or `far`. In these cases, you can give Unity a safe default for these by
 defining this option with the attribute you would like.
 
 _Example:_
+
 ```C
 #define UNITY_PTR_ATTRIBUTE __attribute__((far))
 #define UNITY_PTR_ATTRIBUTE near
 ```
 
-##### `UNITY_PRINT_EOL`
+#### `UNITY_PRINT_EOL`
 
 By default, Unity outputs \n at the end of each line of output. This is easy
 to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR
 system. Feel free to override this and to make it whatever you wish.
 
 _Example:_
+
 ```C
 #define UNITY_PRINT_EOL { UNITY_OUTPUT_CHAR('\r'); UNITY_OUTPUT_CHAR('\n'); }
 ```
 
-
+#### `UNITY_EXCLUDE_DETAILS`
-##### `UNITY_EXCLUDE_DETAILS`
 
 This is an option for if you absolutely must squeeze every byte of memory out of
 your system. Unity stores a set of internal scratchpads which are used to pass
@@ -392,11 +388,12 @@ report which function or argument flagged an error. If you're not using CMock an
 you're not using these details for other things, then you can exclude them.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_DETAILS
 ```
 
-##### `UNITY_PRINT_TEST_CONTEXT`
+#### `UNITY_PRINT_TEST_CONTEXT`
 
 This option allows you to specify your own function to print additional context
 as part of the error message when a test has failed. It can be useful if you
@@ -404,6 +401,7 @@ want to output some specific information about the state of the test at the poin
 of failure, and `UNITY_SET_DETAILS` isn't flexible enough for your needs.
 
 _Example:_
+
 ```C
 #define UNITY_PRINT_TEST_CONTEXT PrintIterationCount
 
@@ -415,7 +413,7 @@ void PrintIterationCount(void)
 }
 ```
 
-##### `UNITY_EXCLUDE_SETJMP`
+#### `UNITY_EXCLUDE_SETJMP`
 
 If your embedded system doesn't support the standard library setjmp, you can
 exclude Unity's reliance on this by using this define. This dropped dependence
@@ -425,23 +423,28 @@ compiler doesn't support setjmp, you wouldn't have had the memory space for thos
 things anyway, though... so this option exists for those situations.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_SETJMP
 ```
 
-##### `UNITY_OUTPUT_COLOR`
+#### `UNITY_OUTPUT_COLOR`
 
 If you want to add color using ANSI escape codes you can use this define.
 
 _Example:_
+
 ```C
 #define UNITY_OUTPUT_COLOR
 ```
 
-##### `UNITY_SHORTHAND_AS_INT`
+#### `UNITY_SHORTHAND_AS_INT`
-##### `UNITY_SHORTHAND_AS_MEM`
+
-##### `UNITY_SHORTHAND_AS_RAW`
+#### `UNITY_SHORTHAND_AS_MEM`
-##### `UNITY_SHORTHAND_AS_NONE`
+
+#### `UNITY_SHORTHAND_AS_RAW`
+
+#### `UNITY_SHORTHAND_AS_NONE`
 
 These options  give you control of the `TEST_ASSERT_EQUAL` and the
 `TEST_ASSERT_NOT_EQUAL` shorthand assertions. Historically, Unity treated the
@@ -450,15 +453,15 @@ comparison using `!=`. This assymetry was confusing, but there was much
 disagreement as to how best to treat this pair of assertions. These four options
 will allow you to specify how Unity will treat these assertions.
 
-  - AS INT - the values will be cast to integers and directly compared. Arguments
+- AS INT - the values will be cast to integers and directly compared. Arguments
-             that don't cast easily to integers will cause compiler errors.
+            that don't cast easily to integers will cause compiler errors.
-  - AS MEM - the address of both values will be taken and the entire object's
+- AS MEM - the address of both values will be taken and the entire object's
-             memory footprint will be compared byte by byte. Directly placing
+            memory footprint will be compared byte by byte. Directly placing
-             constant numbers like `456` as expected values will cause errors.
+            constant numbers like `456` as expected values will cause errors.
-  - AS_RAW - Unity assumes that you can compare the two values using `==` and `!=`
+- AS_RAW - Unity assumes that you can compare the two values using `==` and `!=`
-             and will do so. No details are given about mismatches, because it
+            and will do so. No details are given about mismatches, because it
-             doesn't really know what type it's dealing with.
+            doesn't really know what type it's dealing with.
-  - AS_NONE - Unity will disallow the use of these shorthand macros altogether,
+- AS_NONE - Unity will disallow the use of these shorthand macros altogether,
              insisting that developers choose a more descriptive option.
 
 #### `UNITY_SUPPORT_VARIADIC_MACROS`
@@ -482,8 +485,7 @@ require special help. This special help will usually reside in one of two
 places: the `main()` function or the `RUN_TEST` macro. Let's look at how these
 work.
 
-
+### `main()`
-##### `main()`
 
 Each test module is compiled and run on its own, separate from the other test
 files in your project. Each test file, therefore, has a `main` function. This
@@ -515,8 +517,7 @@ after all the test cases have completed. This allows you to do any needed
 system-wide setup or teardown that might be required for your special
 circumstances.
 
-
+#### `RUN_TEST`
-##### `RUN_TEST`
 
 The `RUN_TEST` macro is called with each test case function. Its job is to
 perform whatever setup and teardown is necessary for executing a single test
@@ -552,12 +553,10 @@ each result set. Again, you could do this by adding lines to this macro. Updates
 to this macro are for the occasions when you need an action before or after
 every single test case throughout your entire suite of tests.
 
-
 ## Happy Porting
 
 The defines and macros in this guide should help you port Unity to just about
 any C target we can imagine. If you run into a snag or two, don't be afraid of
 asking for help on the forums. We love a good challenge!
 
-
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

docs/UnityGettingStartedGuide.md

@@ -17,7 +17,6 @@ rules. Unity has been used with many compilers, including GCC, IAR, Clang,
 Green Hills, Microchip, and MS Visual Studio. It's not much work to get it to
 work with a new target.
 
-
 ### Overview of the Documents
 
 #### Unity Assertions reference
@@ -26,21 +25,18 @@ This document will guide you through all the assertion options provided by
 Unity. This is going to be your unit testing bread and butter. You'll spend more
 time with assertions than any other part of Unity.
 
-
 #### Unity Assertions Cheat Sheet
 
 This document contains an abridged summary of the assertions described in the
 previous document. It's perfect for printing and referencing while you
 familiarize yourself with Unity's options.
 
-
 #### Unity Configuration Guide
 
 This document is the one to reference when you are going to use Unity with a new
 target or compiler. It'll guide you through the configuration options and will
 help you customize your testing experience to meet your needs.
 
-
 #### Unity Helper Scripts
 
 This document describes the helper scripts that are available for simplifying
@@ -49,7 +45,6 @@ included in the auto directory of your Unity installation. Neither Ruby nor
 these scripts are necessary for using Unity. They are provided as a convenience
 for those who wish to use them.
 
-
 #### Unity License
 
 What's an open source project without a license file? This brief document
@@ -57,7 +52,6 @@ describes the terms you're agreeing to when you use this software. Basically, we
 want it to be useful to you in whatever context you want to use it, but please
 don't blame us if you run into problems.
 
-
 ### Overview of the Folders
 
 If you have obtained Unity through Github or something similar, you might be
@@ -82,7 +76,6 @@ everything is configured properly.
 - `auto` - Here you will find helpful Ruby scripts for simplifying your test
 workflow. They are purely optional and are not required to make use of Unity.
 
-
 ## How to Create A Test File
 
 Test files are C files. Most often you will create a single test file for each C
@@ -156,21 +149,27 @@ For that sort of thing, you're going to want to look at the configuration guide.
 This should be enough to get you going, though.
 
 ### Running Test Functions
+
 When writing your own `main()` functions, for a test-runner. There are two ways
 to execute the test.
 
 The classic variant
+
 ``` c
 RUN_TEST(func, linenum)
 ```
+
 or its simpler replacement that starts at the beginning of the function.
+
 ``` c
 RUN_TEST(func)
 ```
+
 These macros perform the necessary setup before the test is called and
-handles cleanup and result tabulation afterwards.
+handles clean-up and result tabulation afterwards.
 
 ### Ignoring Test Functions
+
 There are times when a test is incomplete or not valid for some reason.
 At these times, TEST_IGNORE can be called. Control will immediately be
 returned to the caller of the test, and no failures will be returned.
@@ -182,25 +181,31 @@ TEST_IGNORE()
 
 Ignore this test and return immediately
 
-``` c
+```c
 TEST_IGNORE_MESSAGE (message)
 ```
 
 Ignore this test and return immediately. Output a message stating why the test was ignored.
 
 ### Aborting Tests
+
 There are times when a test will contain an infinite loop on error conditions, or there may be reason to escape from the test early without executing the rest of the test.  A pair of macros support this functionality in Unity.  The first `TEST_PROTECT` sets up the feature, and handles emergency abort cases. `TEST_ABORT` can then be used at any time within the tests to return to the last `TEST_PROTECT` call.
 
+```c
     TEST_PROTECT()
+```
 
 Setup and Catch macro
 
+```c
     TEST_ABORT()
+```
 
 Abort Test macro
 
 Example:
 
+```c
     main()
     {
         if (TEST_PROTECT())
@@ -208,11 +213,10 @@ Example:
             MyTest();
         }
     }
+```
 
 If MyTest calls `TEST_ABORT`, program control will immediately return to `TEST_PROTECT` with a return value of zero.
 
-
-
 ## How to Build and Run A Test File
 
 This is the single biggest challenge to picking up a new unit testing framework,
@@ -225,6 +229,7 @@ You have two really good options for toolchains. Depending on where you're
 coming from, it might surprise you that neither of these options is running the
 unit tests on your hardware.
 There are many reasons for this, but here's a short version:
+
 - On hardware, you have too many constraints (processing power, memory, etc),
 - On hardware, you don't have complete control over all registers,
 - On hardware, unit testing is more challenging,
@@ -247,5 +252,4 @@ This flexibility of separating tests into individual executables allows us to
 much more thoroughly unit test our system and it keeps all the test code out of
 our final release!
 
-
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

docs/UnityHelperScriptsGuide.md

@@ -8,7 +8,6 @@ easier. They are completely optional. If you choose to use them, you'll need a
 copy of Ruby, of course. Just install whatever the latest version is, and it is
 likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
 
-
 ### `generate_test_runner.rb`
 
 Are you tired of creating your own `main` function in your test file? Do you
@@ -114,21 +113,19 @@ test_files.each do |f|
 end
 ```
 
-#### Options accepted by generate_test_runner.rb:
+#### Options accepted by generate_test_runner.rb
 
 The following options are available when executing `generate_test_runner`. You
 may pass these as a Ruby hash directly or specify them in a YAML file, both of
 which are described above. In the `examples` directory, Example 3's Rakefile
 demonstrates using a Ruby hash.
 
-
 ##### `:includes`
 
 This option specifies an array of file names to be `#include`'d at the top of
 your runner C file. You might use it to reference custom types or anything else
 universally needed in your generated runners.
 
-
 ##### `:suite_setup`
 
 Define this option with C code to be executed _before any_ test cases are run.
@@ -138,7 +135,6 @@ option unset and instead provide a `void suiteSetUp(void)` function in your test
 suite.  The linker will look for this symbol and fall back to a Unity-provided
 stub if it is not found.
 
-
 ##### `:suite_teardown`
 
 Define this option with C code to be executed _after all_ test cases have
@@ -151,7 +147,6 @@ option unset and instead provide a `int suiteTearDown(int num_failures)`
 function in your test suite.  The linker will look for this symbol and fall
 back to a Unity-provided stub if it is not found.
 
-
 ##### `:enforce_strict_ordering`
 
 This option should be defined if you have the strict order feature enabled in
@@ -159,7 +154,6 @@ CMock (see CMock documentation). This generates extra variables required for
 everything to run smoothly. If you provide the same YAML to the generator as
 used in CMock's configuration, you've already configured the generator properly.
 
-
 ##### `:externc`
 
 This option should be defined if you are mixing C and CPP and want your test
@@ -206,7 +200,6 @@ This option specifies the pattern for matching acceptable source file extensions
 By default it will accept cpp, cc, C, c, and ino files. If you need a different combination
 of files to search, update this from the default `'(?:cpp|cc|ino|C|c)'`.
 
-
 ### `unity_test_summary.rb`
 
 A Unity test file contains one or more test case functions. Each test case can
@@ -274,5 +267,4 @@ OVERALL UNITY TEST SUMMARY
 
 How convenient is that?
 
-
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

extras/fixture/readme.md

@@ -1,7 +1,7 @@
 # Unity Fixtures
 
 This Framework is an optional add-on to Unity.  By including unity_framework.h in place of unity.h,
-you may now work with Unity in a manner similar to CppUTest.  This framework adds the concepts of 
+you may now work with Unity in a manner similar to CppUTest.  This framework adds the concepts of
 test groups and gives finer control of your tests over the command line.
 
 This framework is primarily supplied for those working through James Grenning's book on Embedded
@@ -9,14 +9,14 @@ Test Driven Development, or those coming to Unity from CppUTest. We should note
 framework glosses over some of the features of Unity, and makes it more difficult
 to integrate with other testing tools like Ceedling and CMock.
 
-# Dependency Notification
+## Dependency Notification
 
 Fixtures, by default, uses the Memory addon as well. This is to make it simple for those trying to
-follow along with James' book. Using them together is completely optional. You may choose to use 
+follow along with James' book. Using them together is completely optional. You may choose to use
 Fixtures without Memory handling by defining `UNITY_FIXTURE_NO_EXTRAS`. It will then stop automatically
 pulling in extras and leave you to do it as desired.
 
-# Usage information
+## Usage information
 
 By default the test executables produced by Unity Fixtures run all tests once, but the behavior can
 be configured with command-line flags. Run the test executable with the `--help` flag for more

extras/memory/readme.md

@@ -1,49 +1,49 @@
 # Unity Memory
 
 This Framework is an optional add-on to Unity.  By including unity.h and then
-unity_memory.h, you have the added ability to track malloc and free calls. This 
+unity_memory.h, you have the added ability to track malloc and free calls. This
 addon requires that the stdlib functions be overridden by its own defines. These
 defines will still malloc / realloc / free etc, but will also track the calls
 in order to ensure that you don't have any memory leaks in your programs.
 
 Note that this is only useful in situations where a unit is in charge of both
-the allocation and deallocation of memory. When it is not symmetric, unit testing 
+the allocation and deallocation of memory. When it is not symmetric, unit testing
 can report a number of false failures. A more advanced runtime tool is required to
 track complete system memory handling.
 
-# Module API
+## Module API
 
-## `UnityMalloc_StartTest` and `UnityMalloc_EndTest`
+### `UnityMalloc_StartTest` and `UnityMalloc_EndTest`
 
 These must be called at the beginning and end of each test. For simplicity, they can
 be added to `setUp` and `tearDown` in order to do their job. When using the test
 runner generator scripts, these will be automatically added to the runner whenever
 unity_memory.h is included.
 
-## `UnityMalloc_MakeMallocFailAfterCount`
+### `UnityMalloc_MakeMallocFailAfterCount`
 
 This can be called from the tests themselves. Passing this function a number will
 force the reference counter to start keeping track of malloc calls. During that test,
-if the number of malloc calls exceeds the number given, malloc will immediately 
+if the number of malloc calls exceeds the number given, malloc will immediately
-start returning `NULL`. This allows you to test error conditions. Think of it as a 
+start returning `NULL`. This allows you to test error conditions. Think of it as a
 simplified mock.
 
-# Configuration
+## Configuration
 
-## `UNITY_MALLOC` and `UNITY_FREE`
+### `UNITY_MALLOC` and `UNITY_FREE`
 
-By default, this module tries to use the real stdlib `malloc` and `free` internally. 
+By default, this module tries to use the real stdlib `malloc` and `free` internally.
-If you would prefer it to use something else, like FreeRTOS's `pvPortMalloc` and 
+If you would prefer it to use something else, like FreeRTOS's `pvPortMalloc` and
 `pvPortFree`, then you can use these defines to make it so.
 
-## `UNITY_EXCLUDE_STDLIB_MALLOC`
+### `UNITY_EXCLUDE_STDLIB_MALLOC`
 
 If you would like this library to ignore stdlib or other heap engines completely, and
 manage the memory on its own, then define this. All memory will be handled internally
 (and at likely lower overhead). Note that this is not a very featureful memory manager,
 but is sufficient for most testing purposes.
 
-## `UNITY_INTERNAL_HEAP_SIZE_BYTES`
+### `UNITY_INTERNAL_HEAP_SIZE_BYTES`
 
 When using the built-in memory manager (see `UNITY_EXCLUDE_STDLIB_MALLOC`) this define
 allows you to set the heap size this library will use to manage the memory.