ceedling 0.31.0 → 0.31.1

data/vendor/unity/auto/generate_test_runner.rb

@@ -143,7 +143,7 @@ class UnityTestRunnerGenerator
         arguments.scan(/\s*TEST_CASE\s*\((.*)\)\s*$/) { |a| args << a[0] }
 
         arguments.scan(/\s*TEST_RANGE\s*\((.*)\)\s*$/).flatten.each do |range_str|
-          args += range_str.scan(/\[(-?\d+.?\d*), *(-?\d+.?\d*), *(-?\d+.?\d*)\]/).map do |arg_values_str|
+          args += range_str.scan(/\[\s*(-?\d+.?\d*),\s*(-?\d+.?\d*),\s*(-?\d+.?\d*)\s*\]/).map do |arg_values_str|
             arg_values_str.map do |arg_value_str|
               arg_value_str.include?('.') ? arg_value_str.to_f : arg_value_str.to_i
             end

data/vendor/unity/docs/ThrowTheSwitchCodingStandard.md

@@ -1,136 +1,116 @@
 # ThrowTheSwitch.org Coding Standard
 
-Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
-we try to follow these standards to unify our contributors' code into a cohesive
-unit (puns intended). You might find places where these standards aren't
-followed. We're not perfect. Please be polite where you notice these discrepancies
-and we'll try to be polite when we notice yours.
+Hi.
+Welcome to the coding standard for ThrowTheSwitch.org.
+For the most part, we try to follow these standards to unify our contributors' code into a cohesive unit (puns intended).
+You might find places where these standards aren't followed.
+We're not perfect. Please be polite where you notice these discrepancies 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.
-
+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
-vision for these tools. We're C developers and embedded software developers.
-These tools are great to test any C code, but catering to embedded software has
-made us more tolerant of compiler quirks. There are a LOT of quirky compilers
-out there. By quirky I mean "doesn't follow standards because they feel like
-they have a license to do as they wish."
-
-Our philosophy is "support every compiler we can". Most often, this means that
-we aim for writing C code that is standards compliant (often C89... that seems
-to be a sweet spot that is almost always compatible). But it also means these
-tools are tolerant of things that aren't common. Some that aren't even
-compliant. There are configuration options to override the size of standard
-types. There are configuration options to force Unity to not use certain
-standard library functions. A lot of Unity is configurable and we have worked
-hard to make it not TOO ugly in the process.
-
-Similarly, our tools that parse C do their best. They aren't full C parsers
-(yet) and, even if they were, they would still have to accept non-standard
-additions like gcc extensions or specifying `@0x1000` to force a variable to
-compile to a particular location. It's just what we do, because we like
-everything to Just Work™.
-
-Speaking of having things Just Work™, that's our second philosophy. By that, we
-mean that we do our best to have EVERY configuration option have a logical
-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.
+Before we get into details on syntax, let's take a moment to talk about our vision for these tools.
+We're C developers and embedded software developers.
+These tools are great to test any C code, but catering to embedded software made us more tolerant of compiler quirks.
+There are a LOT of quirky compilers out there.
+By quirky I mean "doesn't follow standards because they feel like they have a license to do as they wish."
+
+Our philosophy is "support every compiler we can".
+Most often, this means that we aim for writing C code that is standards compliant (often C89... that seems to be a sweet spot that is almost always compatible).
+But it also means these tools are tolerant of things that aren't common.
+Some that aren't even compliant.
+There are configuration options to override the size of standard types.
+There are configuration options to force Unity to not use certain standard library functions.
+A lot of Unity is configurable and we have worked hard to make it not TOO ugly in the process.
 
+Similarly, our tools that parse C do their best.
+They aren't full C parsers (yet) and, even if they were, they would still have to accept non-standard additions like gcc extensions or specifying `@0x1000` to force a variable to compile to a particular location.
+It's just what we do, because we like everything to Just Work™.
+
+Speaking of having things Just Work™, that's our second philosophy.
+By that, we mean that we do our best to have EVERY configuration option have a logical 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
-files, functions, variables, and so much more. While we're not always going to
-find the best name for something, we actually put a bit of effort into
-finding *What Something WANTS to be Called*™.
+Let's talk about naming things.
+Programming is all about naming things.
+We name files, functions, variables, and so much more.
+While we're not always going to find the best name for something, we actually put a bit of effort into 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):
 
-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).
 
-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
-from poking around our code that this often results in names that are a little
-longer than the average. Guilty. We're okay with a bit more typing if it
-means our code is easier to understand.
-
-There are two exceptions to this rule that we also stick to as religiously as
-possible:
-
-First, while we realize hungarian notation (and similar systems for encoding
-type information into variable names) is providing a more descriptive name, we
-feel that (for the average developer) it takes away from readability and is to be avoided.
+Finding the right name for something is an important endeavour.
+You might notice from poking around our code that this often results in names that are a little longer than the average.
+Guilty.
+We're okay with a bit more typing if it means our code is easier to understand.
 
-Second, loop counters and other local throw-away variables often have a purpose
-which is obvious. There's no need, therefore, to get carried away with complex
-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.
+There are two exceptions to this rule that we also stick to as religiously as possible:
 
+First, while we realize hungarian notation (and similar systems for encoding type information into variable names) is providing a more descriptive name, we feel that (for the average developer) it takes away from readability and is to be avoided.
 
-#### Consistent
+Second, loop counters and other local throw-away variables often have a purpose which is obvious.
+There's no need, therefore, to get carried away with complex 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.
 
-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.
+### 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
-
-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
-often we strive for descriptive AND unique... we like quirky names that stand
-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
-requirements, but they don't feel stale.
+### 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 often we strive for descriptive AND unique... we like quirky names that stand 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 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?
-How many spaces? Where do the braces go? These are age-old questions that will
-never be answered... or at least not answered in a way that will make everyone
-happy.
-
-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.
+We don't really want to add to the style battles out there.
+Tabs or spaces?
+How many spaces?
+Where do the braces go?
+These are age-old questions that will never be answered... or at least not answered in a way that will make everyone happy.
 
+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
+### Whitespace in C/C++
 
-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
-than that. We break that rule when we have lines that wrap (macros or function
-arguments or whatnot). When that happens, we like to indent further to line
-things up in nice tidy columns.
+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 than that.
+We break that rule when we have lines that wrap (macros or function arguments or whatnot).
+When that happens, we like to indent further to line things up in nice tidy columns.
 
 ```C
     if (stuff_happened)
@@ -139,8 +119,7 @@ things up in nice tidy columns.
     }
 ```
 
-
-#### Case
+### Case in C/C++
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -149,12 +128,12 @@ 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
-catching an error and you have a one-line, go ahead and to it on the same line.
+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 catching an error and you have a one-line, go ahead and to it on the same line.
 
 ```C
     while (blah)
@@ -163,32 +142,32 @@ 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,
-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.
-
+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, 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!
-
+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
+### Whitespace in Ruby
 
-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.
+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
+### Case in Ruby
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -196,11 +175,13 @@ 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?
+Egad.
+Really?
+We use markdown 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][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[ThrowTheSwitch.org]: https://throwtheswitch.org

data/vendor/unity/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
@@ -36,7 +34,7 @@ execution and reports an error through some appropriate I/O channel (e.g.
 stdout, GUI, file, blinky light).
 
 Fundamentally, for dynamic verification all you need is a single assertion
-mechanism. In fact, that's what the [assert() macro in C's standard library](http://en.wikipedia.org/en/wiki/Assert.h)
+mechanism. In fact, that's what the [assert() macro][] in C's standard library
 is for. So why not just use it? Well, we can do far better in the reporting
 department. C's `assert()` is pretty dumb as-is and is particularly poor for
 handling common data types like arrays, structs, etc. And, without some other
@@ -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
-    assertion construction is the only parameter present in all assertion variants.
- - `Modifiers` are masks, ranges, bit flag specifiers, floating point deltas.
- - `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
-    `actual` parameter (e.g. null check).
- - `Size/count` refers to string lengths, number of array elements, etc.
+- `Actual` is the value being tested and unlike the other parameters in an
+  assertion construction is the only parameter present in all assertion variants.
+- `Modifiers` are masks, ranges, bit flag specifiers, floating point deltas.
+- `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
+  `actual` parameter (e.g. null check).
+- `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.
- - `Size/count` is one or two parameters necessary to establish the number of array
-    elements and perhaps the length of elements within the array.
+- `Expected` is an array itself.
+- `Size/count` is one or two parameters necessary to establish the number of array
+  elements and perhaps the length of elements within the array.
 
 Notes:
 
- - The `_MESSAGE` variant convention still applies here to array assertions. The
-   `_MESSAGE` variants of the `_ARRAY` assertions have names ending with
-   `_ARRAY_MESSAGE`.
- - Assertions for handling arrays of floating point values are grouped with float
-   and double assertions (see immediately following section).
-
+- The `_MESSAGE` variant convention still applies here to array assertions. The
+  `_MESSAGE` variants of the `_ARRAY` assertions have names ending with
+  `_ARRAY_MESSAGE`.
+- Assertions for handling arrays of floating point values are grouped with float
+  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.
- - `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
-    elements and perhaps the length of elements within the array.
+- `Expected` is a single value to compare to.
+- `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
+  elements and perhaps the length of elements within the array.
 
 Notes:
 
- - The `_MESSAGE` variant convention still applies here to Each Equal assertions.
- - Assertions for handling Each Equal of floating point values are grouped with
-   float and double assertions (see immediately following section).
-
+- The `_MESSAGE` variant convention still applies here to Each Equal assertions.
+- Assertions for handling Each Equal of floating point values are grouped with
+  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_UINT64 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_UINT32 (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_HEX8 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
 
-##### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
+#### `TEST_ASSERT_EQUAL_HEX32 (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_NOT_EQUAL_UINT8 (threshold, actual)`
+#### `TEST_ASSERT_LESS_OR_EQUAL_UINT (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,7 @@ 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][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[assert() macro]: http://en.wikipedia.org/en/wiki/Assert.h
+[ThrowTheSwitch.org]: https://throwtheswitch.org