Merge remote-tracking branch 'upstream/master' into more-float

# Conflicts: # README.md # docs/UnityAssertionsReference.md
2026-01-23 00:15:58 +01:00 · 2021-07-27 01:54:26 +02:00
parent 410de1a02b aeed24c78b
commit d06ac64852
12 changed files with 824 additions and 974 deletions
--- a/README.md
+++ b/README.md
@@ -1,29 +1,26 @@
-Unity Test ![CI](https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg)
+# Unity Test ![CI][]
-==========
+
 __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.
-unit testing framework built for C, with a focus on working with embedded toolchains. 
+Unity Test is a 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.
-single C file and a pair of headers, allowing it to the added to your existing build setup without 
+The core project is a single C file and a pair of headers, allowing it to the added to your existing build setup without too much headache.
-too much headache. You may use any compiler you wish, and may use most existing build systems
+You may use any compiler you wish, and may use most existing build systems including Make, CMake, etc.
-including make, cmake, etc. If you'd like to leave the hard work to us, you might be interested
+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)
+If you're new to Unity, we encourage you to tour the [getting started guide][].
-Getting Started
+## Getting Started
 ===============
 The [docs](docs/) folder contains a [getting started guide](docs/UnityGettingStartedGuide.md)
 and much more tips about using Unity. 
-Unity Assertion Summary
+The [docs][] folder contains a [getting started guide][] and much more tips about using Unity.
 =======================
 For the full list, see [UnityAssertionsReference.md](docs/UnityAssertionsReference.md).
-Basic Validity Tests
+## Unity Assertion Summary
--------------------
+
 For the full list, see [UnityAssertionsReference.md][].
 ### Basic Validity Tests
    TEST_ASSERT_TRUE(condition)
@@ -44,10 +41,10 @@ Another way of calling `TEST_ASSERT_FALSE`
    TEST_FAIL()
    TEST_FAIL_MESSAGE(message)
-This test is automatically marked as a failure. The message is output stating why.
+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)
@@ -55,9 +52,9 @@ Numerical Assertions: Integers
    TEST_ASSERT_EQUAL_INT32(expected, actual)
    TEST_ASSERT_EQUAL_INT64(expected, actual)
-Compare two integers for equality and display errors as signed integers. A cast will be performed
+Compare two integers for equality and display errors as signed integers.
-to your natural integer size so often this can just be used. When you need to specify the exact size,
+A cast will be performed to your natural integer size so often this can just be used.
-like when comparing arrays, you can use a specific version:
+When you need to specify the exact size, like when comparing arrays, you can use a specific version:
    TEST_ASSERT_EQUAL_UINT(expected, actual)
    TEST_ASSERT_EQUAL_UINT8(expected, actual)
@@ -65,8 +62,8 @@ like when comparing arrays, you can use a specific version:
    TEST_ASSERT_EQUAL_UINT32(expected, actual)
    TEST_ASSERT_EQUAL_UINT64(expected, actual)
-Compare two integers for equality and display errors as unsigned integers. Like INT, there are
+Compare two integers for equality and display errors as unsigned integers.
-variants for different sizes also.
+Like INT, there are variants for different sizes also.
    TEST_ASSERT_EQUAL_HEX(expected, actual)
    TEST_ASSERT_EQUAL_HEX8(expected, actual)
@@ -74,9 +71,8 @@ variants for different sizes also.
    TEST_ASSERT_EQUAL_HEX32(expected, actual)
    TEST_ASSERT_EQUAL_HEX64(expected, actual)
-Compares two integers for equality and display errors as hexadecimal. Like the other integer comparisons,
+Compares two integers for equality and display errors as hexadecimal.
-you can specify the size... here the size will also effect how many nibbles are shown (for example, `HEX16`
+Like the other integer comparisons, you can specify the size... here the size will also effect how many nibbles are shown (for example, `HEX16` will show 4 nibbles).
 will show 4 nibbles).
    TEST_ASSERT_EQUAL(expected, actual)
@@ -84,63 +80,66 @@ Another way of calling TEST_ASSERT_EQUAL_INT
    TEST_ASSERT_INT_WITHIN(delta, expected, actual)
-Asserts that the actual value is within plus or minus delta of the expected value. This also comes in
+Asserts that the actual value is within plus or minus delta of the expected value.
-size specific variants.
+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.
+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.
+Asserts that the actual value is less than the threshold.
 This also comes in size specific variants.
-
+### Arrays
 Arrays
 ------
    _ARRAY
-You can append `_ARRAY` to any of these macros to make an array comparison of that type.  Here you will
+You can append `_ARRAY` to any of these macros to make an array comparison of that type.
-need to care a bit more about the actual size of the value being checked.  You will also specify an
+Here you will need to care a bit more about the actual size of the value being checked.
-additional argument which is the number of elements to compare.  For example:
+You will also specify an additional argument which is the number of elements to compare.
 For example:
    TEST_ASSERT_EQUAL_HEX8_ARRAY(expected, actual, elements)
    _EACH_EQUAL
-Another array comparison option is to check that EVERY element of an array is equal to a single expected
+Another array comparison option is to check that EVERY element of an array is equal to a single expected value.
-value. You do this by specifying the EACH_EQUAL macro. For example:
+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)
-Use an integer mask to specify which bits should be compared between two other integers.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be compared between two other integers.
 High bits in the mask are compared, low bits ignored.
    TEST_ASSERT_BITS_HIGH(mask, actual)
-Use an integer mask to specify which bits should be inspected to determine if they are all set high.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be inspected to determine if they are all set high.
 High bits in the mask are compared, low bits ignored.
    TEST_ASSERT_BITS_LOW(mask, actual)
-Use an integer mask to specify which bits should be inspected to determine if they are all set low.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be inspected to determine if they are all set low.
 High bits in the mask are compared, low bits ignored.
    TEST_ASSERT_BIT_HIGH(bit, actual)
-Test a single bit and verify that it is high.  The bit is specified 0-31 for a 32-bit integer.
+Test a single bit and verify that it is high.
 The bit is specified 0-31 for a 32-bit integer.
    TEST_ASSERT_BIT_LOW(bit, actual)
-Test a single bit and verify that it is low.  The bit is specified 0-31 for a 32-bit integer.
+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)
@@ -158,29 +157,34 @@ Asserts that two floating point values are "equal" within a small % delta of the
 Asserts that the actual value is less than or greater than the threshold.
-String Assertions
+### String Assertions
 -----------------
    TEST_ASSERT_EQUAL_STRING(expected, actual)
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different.
+Compare two null-terminate strings.
 Fail if any character is different or if the lengths are different.
    TEST_ASSERT_EQUAL_STRING_LEN(expected, actual, len)
-Compare two strings.  Fail if any character is different, stop comparing after len characters.
+Compare two strings.
 Fail if any character is different, stop comparing after len characters.
    TEST_ASSERT_EQUAL_STRING_MESSAGE(expected, actual, message)
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different. Output a custom message on failure.
+Compare two null-terminate strings.
 Fail if any character is different or if the lengths are different.
 Output a custom message on failure.
    TEST_ASSERT_EQUAL_STRING_LEN_MESSAGE(expected, actual, len, message)
-Compare two strings. Fail if any character is different, stop comparing after len characters. Output a custom message on failure.
+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.
+Most pointer operations can be performed by simply using the integer comparisons above.
 However, a couple of special cases are added for clarity.
    TEST_ASSERT_NULL(pointer)
@@ -190,18 +194,20 @@ 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
+Compare two blocks of memory.
-standard types... but since it's a memory compare, you have to be careful that your data types are packed.
+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.
-is a string that will be printed at the end of the failure strings.  This is useful for specifying more
+This argument is a string that will be printed at the end of the failure strings.
-information about the problem.
+This is useful for specifying more information about the problem.
 [CI]: https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg
 [getting started guide]: docs/UnityGettingStartedGuide.md
 [docs]: docs/
 [UnityAssertionsReference.md]: docs/UnityAssertionsReference.md
--- a/auto/generate_test_runner.rb
+++ b/auto/generate_test_runner.rb
@@ -212,8 +212,10 @@ class UnityTestRunnerGenerator
  def create_header(output, mocks, testfile_includes = [])
    output.puts('/* AUTOGENERATED FILE. DO NOT EDIT. */')
    output.puts("\n/*=======Automagically Detected Files To Include=====*/")
    output.puts('extern "C" {') if @options[:externcincludes]
    output.puts("#include \"#{@options[:framework]}.h\"")
    output.puts('#include "cmock.h"') unless mocks.empty?
    output.puts('}') if @options[:externcincludes]
    if @options[:defines] && !@options[:defines].empty?
      @options[:defines].each { |d| output.puts("#ifndef #{d}\n#define #{d}\n#endif /* #{d} */") }
    end
@@ -227,9 +229,11 @@ class UnityTestRunnerGenerator
        output.puts("#include #{inc.include?('<') ? inc : "\"#{inc}\""}")
      end
    end
    output.puts('extern "C" {') if @options[:externcincludes]
    mocks.each do |mock|
      output.puts("#include \"#{mock}\"")
    end
    output.puts('}') if @options[:externcincludes]
    output.puts('#include "CException.h"') if @options[:plugins].include?(:cexception)
    return unless @options[:enforce_strict_ordering]
@@ -465,6 +469,9 @@ if $0 == __FILE__
    when '-cexception'
      options[:plugins] = [:cexception]
      true
    when '-externcincludes'
      options[:externcincludes] = true
      true
    when /\.*\.ya?ml$/
      options = UnityTestRunnerGenerator.grab_config(arg)
      true
--- a/docs/ThrowTheSwitchCodingStandard.md
+++ b/docs/ThrowTheSwitchCodingStandard.md
@@ -1,136 +1,116 @@
 # ThrowTheSwitch.org Coding Standard
-Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
+Hi.
-we try to follow these standards to unify our contributors' code into a cohesive
+Welcome to the coding standard for ThrowTheSwitch.org.
-unit (puns intended). You might find places where these standards aren't
+For the most part, we try to follow these standards to unify our contributors' code into a cohesive unit (puns intended).
-followed. We're not perfect. Please be polite where you notice these discrepancies
+You might find places where these standards aren't followed.
-and we'll try to be polite when we notice yours.
+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
+Being consistent makes code easier to understand.
-our standard simple because we also believe that we can only expect someone to
+We've tried to keep our standard simple because we also believe that we can only expect someone to follow something that is understandable.
-follow something that is understandable. Please do your best.
+Please do your best.
 ## Our Philosophy
-Before we get into details on syntax, let's take a moment to talk about our
+Before we get into details on syntax, let's take a moment to talk about our vision for these tools.
-vision for these tools. We're C developers and embedded software developers.
+We're C developers and embedded software developers.
-These tools are great to test any C code, but catering to embedded software has
+These tools are great to test any C code, but catering to embedded software made us more tolerant of compiler quirks.
-made us more tolerant of compiler quirks. There are a LOT of quirky compilers
+There are a LOT of quirky compilers out there.
-out there. By quirky I mean "doesn't follow standards because they feel like
+By quirky I mean "doesn't follow standards because they feel like they have a license to do as they wish."
 they have a license to do as they wish."
-Our philosophy is "support every compiler we can". Most often, this means that
+Our philosophy is "support every compiler we can".
-we aim for writing C code that is standards compliant (often C89... that seems
+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).
-to be a sweet spot that is almost always compatible). But it also means these
+But it also means these tools are tolerant of things that aren't common.
-tools are tolerant of things that aren't common. Some that aren't even
+Some that aren't even compliant.
-compliant. There are configuration options to override the size of standard
+There are configuration options to override the size of standard types.
-types. There are configuration options to force Unity to not use certain
+There are configuration options to force Unity to not use certain standard library functions.
-standard library functions. A lot of Unity is configurable and we have worked
+A lot of Unity is configurable and we have worked hard to make it not TOO ugly in the process.
 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
+Similarly, our tools that parse C do their best.
-(yet) and, even if they were, they would still have to accept non-standard
+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.
-additions like gcc extensions or specifying `@0x1000` to force a variable to
+It's just what we do, because we like everything to Just Work™.
 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.
 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
+Let's talk about naming things.
-files, functions, variables, and so much more. While we're not always going to
+Programming is all about naming things.
-find the best name for something, we actually put a bit of effort into
+We name files, functions, variables, and so much more.
-finding *What Something WANTS to be Called*™.
+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
+### Descriptive
 naturally read. We try to avoid double negatives. We try to avoid cryptic
 abbreviations (sticking to ones we feel are common).
 #### Descriptive
 We like descriptive names for things, especially functions and variables.
-Finding the right name for something is an important endeavor. You might notice
+Finding the right name for something is an important endeavour.
-from poking around our code that this often results in names that are a little
+You might notice from poking around our code that this often results in names that are a little longer than the average.
-longer than the average. Guilty. We're okay with a bit more typing if it
+Guilty.
-means our code is easier to understand.
+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
+There are two exceptions to this rule that we also stick to as religiously as possible:
 possible:
-First, while we realize hungarian notation (and similar systems for encoding
+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.
 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.
-Second, loop counters and other local throw-away variables often have a purpose
+Second, loop counters and other local throw-away variables often have a purpose which is obvious.
-which is obvious. There's no need, therefore, to get carried away with complex
+There's no need, therefore, to get carried away with complex naming.
-naming. We find i, j, and k are better loop counters than loopCounterVar or
+We find i, j, and k are better loop counters than loopCounterVar or whatnot.
-whatnot. We only break this rule when we see that more description could improve
+We only break this rule when we see that more description could improve understanding of an algorithm.
 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.
-We like consistency, but we're not really obsessed with it. We try to name our
+### Memorable
 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.
 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?
+We don't really want to add to the style battles out there.
-How many spaces? Where do the braces go? These are age-old questions that will
+Tabs or spaces?
-never be answered... or at least not answered in a way that will make everyone
+How many spaces?
-happy.
+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
+We've decided on our own style preferences.
-projects (and we hope that you do), then we ask if you do your best to follow
+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.
-the same. It will only hurt a little. We promise.
+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.
-Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
+We have no more reason than that.
-power-of-2 number that looks decent on a wide-screen. We have no more reason
+We break that rule when we have lines that wrap (macros or function arguments or whatnot).
-than that. We break that rule when we have lines that wrap (macros or function
+When that happens, we like to indent further to line things up in nice tidy columns.
 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 in C/C++
 #### Case
 - 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.
-The left brace is on the next line after the declaration. The right brace is
+Everything in between in indented one level.
-directly below that. Everything in between in indented one level. If you're
+If you're catching an error and you have a one-line, go ahead and to it on the same line.
 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.
-Do you know what we hate? Old-school C block comments. BUT, we're using them
+BUT, we're using them anyway.
-anyway. As we mentioned, our goal is to support every compiler we can,
+As we mentioned, our goal is to support every compiler we can, especially embedded compilers.
-especially embedded compilers. There are STILL C compilers out there that only
+There are STILL C compilers out there that only support old-school block comments.
-support old-school block comments. So that is what we're using. We apologize. We
+So that is what we're using.
-think they are ugly too.
+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
+Is there really such thing as a Ruby coding standard?
-language, it seems almost sacrilegious to suggest that people should comply to
+Ruby is such a free form language, it seems almost sacrilegious to suggest that people should comply to one method!
-one method! We'll keep it really brief!
+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.
-Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
+### Case in Ruby
 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
 - 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
+Egad.
-look nice while still being portable. Good enough?
+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
--- a/docs/UnityAssertionsReference.md
+++ b/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
+- `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,88 +563,75 @@ 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 `TEST_ASSERT_EQUAL_FLOAT`.That is, user
 specified delta comparison values requires a custom-implemented floating point
 array assertion.
-
+#### `TEST_ASSERT_LESS_THAN_FLOAT (threshold, actual)`
 ##### `TEST_ASSERT_LESS_THAN_FLOAT (threshold, actual)`
 Asserts that the `actual` parameter is less than `threshold` (exclusive).
 For example, if the threshold value is 1.0f, the assertion will fail if it is
 greater than 1.0f.
-
+#### `TEST_ASSERT_GREATER_THAN_FLOAT (threshold, actual)`
 ##### `TEST_ASSERT_GREATER_THAN_FLOAT (threshold, actual)`
 Asserts that the `actual` parameter is greater than `threshold` (exclusive).
 For example, if the threshold value is 1.0f, the assertion will fail if it is
 less than 1.0f.
-
+#### `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
@@ -675,78 +639,66 @@ 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_LESS_THAN_DOUBLE (threshold, actual)`
 ##### `TEST_ASSERT_LESS_THAN_DOUBLE (threshold, actual)`
 Asserts that the `actual` parameter is less than `threshold` (exclusive).
 For example, if the threshold value is 1.0, the assertion will fail if it is
 greater than 1.0.
-
+#### `TEST_ASSERT_GREATER_THAN_DOUBLE (threshold, actual)`
 ##### `TEST_ASSERT_GREATER_THAN_DOUBLE (threshold, actual)`
 Asserts that the `actual` parameter is greater than `threshold` (exclusive).
 For example, if the threshold value is 1.0, the assertion will fail if it is
 less than 1.0.
-
+#### `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
@@ -755,7 +707,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
@@ -796,7 +747,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
@@ -855,5 +805,7 @@ affect you:
   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
--- a/docs/UnityConfigurationGuide.md
+++ b/docs/UnityConfigurationGuide.md
@@ -2,133 +2,118 @@
 ## C Standards, Compilers and Microcontrollers
-The embedded software world contains its challenges. Compilers support different
+The embedded software world contains its challenges.
-revisions of the C Standard. They ignore requirements in places, sometimes to
+Compilers support different revisions of the C Standard.
-make the language more usable in some special regard. Sometimes it's to simplify
+They ignore requirements in places, sometimes to make the language more usable in some special regard.
-their support. Sometimes it's due to specific quirks of the microcontroller they
+Sometimes it's to simplify their support.
-are targeting. Simulators add another dimension to this menagerie.
+Sometimes it's due to specific quirks of the microcontroller they are targeting.
 Simulators add another dimension to this menagerie.
-Unity is designed to run on almost anything that is targeted by a C compiler. It
+Unity is designed to run on almost anything that is targeted by a C compiler.
-would be awesome if this could be done with zero configuration. While there are
+It would be awesome if this could be done with zero configuration.
-some targets that come close to this dream, it is sadly not universal. It is
+While there are some targets that come close to this dream, it is sadly not universal.
-likely that you are going to need at least a couple of the configuration options
+It is likely that you are going to need at least a couple of the configuration options described in this document.
 described in this document.
 All of Unity's configuration options are `#defines`. Most of these are simple
 definitions. A couple are macros with arguments. They live inside the
 unity_internals.h header file. We don't necessarily recommend opening that file
 unless you really need to. That file is proof that a cross-platform library is
 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.
 All of Unity's configuration options are `#defines`.
 Most of these are simple definitions.
 A couple are macros with arguments.
 They live inside the unity_internals.h header file.
 We don't necessarily recommend opening that file unless you really need to.
 That file is proof that a cross-platform library is 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
+It doesn't matter if you're using a target-specific compiler and a simulator or a native compiler.
-a native compiler. In either case, you've got a couple choices for configuring
+In either case, you've got a couple choices for configuring these options:
 these options:
-1. Because these options are specified via C defines, you can pass most of these
+1. Because these options are specified via C defines, you can pass most of these options to your compiler through command line compiler flags. Even if you're using an embedded target that forces you to use their overbearing IDE for all configuration, there will be a place somewhere in your project to configure defines for your compiler.
-options to your compiler through command line compiler flags. Even if you're
+2. You can create a custom `unity_config.h` configuration file (present in your toolchain's search paths).
-using an embedded target that forces you to use their overbearing IDE for all
+  In this file, you will list definitions and macros specific to your target. All you must do is define `UNITY_INCLUDE_CONFIG_H` and Unity will rely on `unity_config.h` for any further definitions it may need.
 configuration, there will be a place somewhere in your project to configure
 defines for your compiler.
 2. You can create a custom `unity_config.h` configuration file (present in your
 toolchain's search paths). In this file, you will list definitions and macros
 specific to your target. All you must do is define `UNITY_INCLUDE_CONFIG_H` and
 Unity will rely on `unity_config.h` for any further definitions it may need.
-Unfortunately, it doesn't usually work well to just #define these things in the
+Unfortunately, it doesn't usually work well to just #define these things in the test itself.
-test itself. These defines need to take effect where ever unity.h is included.
+These defines need to take effect where ever unity.h is included.
-This would be test test, the test runner (if you're generating one), and from
+This would be test test, the test runner (if you're generating one), and from unity.c when it's compiled.
 unity.c when it's compiled.
 ## The Options
 ### Integer Types
-If you've been a C developer for long, you probably already know that C's
+If you've been a C developer for long, you probably already know that C's concept of an integer varies from target to target.
-concept of an integer varies from target to target. The C Standard has rules
+The C Standard has rules about the `int` matching the register size of the target microprocessor.
-about the `int` matching the register size of the target microprocessor. It has
+It has rules about the `int` and how its size relates to other integer types.
-rules about the `int` and how its size relates to other integer types. An `int`
+An `int` on one target might be 16 bits while on another target it might be 64.
-on one target might be 16 bits while on another target it might be 64. There are
+There are more specific types in compilers compliant with C99 or later, but that's certainly not every compiler you are likely to encounter.
-more specific types in compilers compliant with C99 or later, but that's
+Therefore, Unity has a number of features for helping to adjust itself to match your required integer sizes.
-certainly not every compiler you are likely to encounter. Therefore, Unity has a
+It starts off by trying to do it automatically.
 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
+This file includes defines like `UINT_MAX` that Unity can use to learn a lot about your system.
-learn a lot about your system. It's possible you don't want it to do this
+It's possible you don't want it to do this (um. why not?) or (more likely) it's possible that your system doesn't support `stdint.h`.
-(um. why not?) or (more likely) it's possible that your system doesn't
+If that's the case, you're going to want to define this.
-support `stdint.h`. If that's the case, you're going to want to define this.
+That way, Unity will know to skip the inclusion of this file and you won't be left with a compiler error.
 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.
-The second attempt to guess your types is to check `limits.h`. Some compilers
+If you don't want Unity to check this file either, define this to make it skip the inclusion.
 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
 ```
-If you've disabled both of the automatic options above, you're going to have to
+If you've disabled both of the automatic options above, you're going to have to do the configuration yourself.
-do the configuration yourself. Don't worry. Even this isn't too bad... there are
+Don't worry.
-just a handful of defines that you are going to specify if you don't like the
+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.
 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.
 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.
-Define this to be the number of bits a `long` takes up on your system. The
+This is used to figure out what kind of 64-bit support your system can handle.
-default, if not autodetected, is 32 bits. This is used to figure out what kind
+Does it need to specify a `long` or a `long long` to get a 64-bit value.
-of 64-bit support your system can handle. Does it need to specify a `long` or a
+On 16-bit systems, this option is going to be ignored.
 `long long` to get a 64-bit value. On 16-bit systems, this option is going to be
 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 warnings about casting from pointers, this is the one to look at.
-Define this to be the number of bits a pointer takes up on your system. The
+_Hint:_ In order to support exotic processors (for example TI C55x with a pointer width of 23-bit), choose the next power of two (in this case 32-bit).
 default, if not autodetected, is 32-bits. If you're getting ugly compiler
 warnings about casting from pointers, this is the one to look at.
 _Hint:_ In order to support exotic processors (for example TI C55x with a pointer
 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,137 +121,117 @@ _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 enable 64-bit support if none of the other options already did it for you.
-Unity will automatically include 64-bit support if it auto-detects it, or if
+There 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.
 your `int`, `long`, or pointer widths are greater than 32-bits. Define this to
 enable 64-bit support if none of the other options already did it for you. There
 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
+In the embedded world, it's not uncommon for targets to have no support for floating point operations at all or to have support that is limited to only single precision.
-floating point operations at all or to have support that is limited to only
+We are able to guess integer sizes on the fly because integers are always available in at least one size.
-single precision. We are able to guess integer sizes on the fly because integers
+Floating point, on the other hand, is sometimes not available at all.
-are always available in at least one size. Floating point, on the other hand, is
+Trying to include `float.h` on these platforms would result in an error. This leaves manual configuration as the only option.
 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 include and exclude options here.
-By default, Unity guesses that you will want single precision floating point
+You may include neither, either, or both, as suits your needs.
-support, but not double precision. It's easy to change either of these using the
+For features that are enabled, the following floating point options also become available.
 include and exclude options here. You may include neither, either, or both, as
 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 of this, its routines for printing integer values are minimalist and hand-coded.
 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
 of this, its routines for printing integer values are minimalist and hand-coded.
 Therefore, the display of floating point values during a failure are optional.
-By default, Unity will print the actual results of floating point assertion
+By default, Unity will print the actual results of floating point assertion failure (e.g. ”Expected 4.56 Was 4.68”).
-failure (e.g. ”Expected 4.56 Was 4.68”). To not include this extra support, you
+To not include this extra support, you can use this define to instead respond to a failed assertion with a message like ”Values Not Within Delta”.
-can use this define to instead respond to a failed assertion with a message like
+If you would like verbose failure messages for floating point assertions, use these options to give more explicit failure messages.
 ”Values Not Within Delta”. If you would like verbose failure messages for floating
 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.
 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 using this option.
-If enabled, Unity assumes you want your `DOUBLE` asserts to compare standard C
+For example, defining `UNITY_DOUBLE_TYPE` to `long double` could enable gargantuan floating point types on your 64-bit processor instead of the standard `double`.
 doubles. If you would like to change this, you can specify something else by
 using this option. For example, defining `UNITY_DOUBLE_TYPE` to `long double`
 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 not really asserting that two values are equal but rather that two values are "close enough" to equal.
-
+"Close enough" is controlled by these precision configuration options.
-If you look up `UNITY_ASSERT_EQUAL_FLOAT` and `UNITY_ASSERT_EQUAL_DOUBLE` as
+If you are working with 32-bit floats and/or 64-bit doubles (the normal on most processors), you should have no need to change these options.
-documented in the big daddy Unity Assertion Guide, you will learn that they are
+They are both set to give you approximately 1 significant bit in either direction.
-not really asserting that two values are equal but rather that two values are
+The float precision is 0.00001 while the double is 10-12.
-"close enough" to equal. "Close enough" is controlled by these precision
+For further details on how this works, see the appendix of the Unity Assertion Guide.
 configuration options. If you are working with 32-bit floats and/or 64-bit
 doubles (the normal on most processors), you should have no need to change these
 options. They are both set to give you approximately 1 significant bit in either
 direction. The float precision is 0.00001 while the double is 10-12.
 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,
+Unity uses the `NULL` macro, which defines the value of a null pointer constant, defined in `stddef.h` by default.
-defined in `stddef.h` by default. If you want to provide
+If you want to provide your own macro for this, you should exclude the `stddef.h` header file by adding this define to your configuration.
 your own macro for this, you should exclude the `stddef.h` header file by adding this
 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,
+Unity provides a simple (and very basic) printf-like string output implementation, which is able to print a string modified by the following format string modifiers:
 which is able to print a string modified by the following format string modifiers:
 - __%d__ - signed value (decimal)
 - __%i__ - same as __%i__
@@ -282,6 +247,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,39 +266,32 @@ 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
+In addition to the options listed above, there are a number of other options which will come in handy to customize Unity's behavior for your specific toolchain.
-which will come in handy to customize Unity's behavior for your specific
+It is possible that you may not need to touch any of these... but certain platforms, particularly those running in simulators, may need to jump through extra hoops to run properly.
-toolchain. It is possible that you may not need to touch any of these... but
+These macros will help in those situations.
 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 testing.
-By default, Unity prints its results to `stdout` as it runs. This works
+It works on some simulators as well so long as they have `stdout` routed back to the command line.
-perfectly fine in most situations where you are using a native compiler for
+There are times, however, where the simulator will lack support for dumping results or you will want to route results elsewhere for other reasons.
-testing. It works on some simulators as well so long as they have `stdout`
+In these cases, you should define the `UNITY_OUTPUT_CHAR` macro.
-routed back to the command line. There are times, however, where the simulator
+This macro accepts a single character at a time (as an `int`, since this is the parameter type of the standard C `putchar` function most commonly used).
-will lack support for dumping results or you will want to route results
+You may replace this with whatever function call you like.
 elsewhere for other reasons. In these cases, you should define the
 `UNITY_OUTPUT_CHAR` macro. This macro accepts a single character at a time (as
 an `int`, since this is the parameter type of the standard C `putchar` function
 most commonly used). You may replace this with whatever function call you like.
 _Example:_
-Say you are forced to run your test suite on an embedded processor with no
+Say you are forced to run your test suite on an embedded processor with no `stdout` option.
-`stdout` option. You decide to route your test result output to a custom serial
+You decide to route your test result output to a custom serial `RS232_putc()` function you wrote like thus:
-`RS232_putc()` function you wrote like thus:
+
 ```C
 #include "RS232_header.h"
 ...
@@ -343,67 +302,63 @@ Say you are forced to run your test suite on an embedded processor with no
 ```
 _Note:_
-`UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by
+`UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by specifying `UNITY_USE_FLUSH_STDOUT`.
-specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
+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.
-When managing your own builds, it is often handy to have messages output in a format which is
+#### `UNITY_PTR_ATTRIBUTE`
 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.
-
+Some compilers require a custom attribute to be assigned to pointers, like `near` or `far`.
-##### `UNITY_PTR_ATTRIBUTE`
+In these cases, you can give Unity a safe default for these by defining this option with the attribute you would like.
 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
+By default, Unity outputs \n at the end of each line of output.
-to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR
+This is easy to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR system.
-system. Feel free to override this and to make it whatever you wish.
+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 extra detail information around.
-This is an option for if you absolutely must squeeze every byte of memory out of
+It's used by systems like CMock in order to report which function or argument flagged an error.
-your system. Unity stores a set of internal scratchpads which are used to pass
+If you're not using CMock and you're not using these details for other things, then you can exclude them.
 extra detail information around. It's used by systems like CMock in order to
 report which function or argument flagged an error. If you're not using CMock and
 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
+This option allows you to specify your own function to print additional context as part of the error message when a test has failed.
-as part of the error message when a test has failed. It can be useful if you
+It can be useful if you want to output some specific information about the state of the test at the point of failure, and `UNITY_SET_DETAILS` isn't flexible enough for your needs.
 want to output some specific information about the state of the test at the point
 of failure, and `UNITY_SET_DETAILS` isn't flexible enough for your needs.
 _Example:_
 ```C
 #define UNITY_PRINT_TEST_CONTEXT PrintIterationCount
@@ -415,82 +370,74 @@ void PrintIterationCount(void)
 }
 ```
-##### `UNITY_EXCLUDE_SETJMP`
+#### `UNITY_EXCLUDE_SETJMP`
-If your embedded system doesn't support the standard library setjmp, you can
+If your embedded system doesn't support the standard library setjmp, you can exclude Unity's reliance on this by using this define.
-exclude Unity's reliance on this by using this define. This dropped dependence
+This dropped dependence comes at a price, though.
-comes at a price, though. You will be unable to use custom helper functions for
+You will be unable to use custom helper functions for your tests, and you will be unable to use tools like CMock.
-your tests, and you will be unable to use tools like CMock. Very likely, if your
+Very likely, if your compiler doesn't support setjmp, you wouldn't have had the memory space for those things anyway, though... so this option exists for those situations.
 compiler doesn't support setjmp, you wouldn't have had the memory space for those
 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_NONE`
-These options  give you control of the `TEST_ASSERT_EQUAL` and the
+#### `UNITY_SHORTHAND_AS_MEM`
 `TEST_ASSERT_NOT_EQUAL` shorthand assertions. Historically, Unity treated the
 former as an alias for an integer comparison. It treated the latter as a direct
 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
+#### `UNITY_SHORTHAND_AS_RAW`
-             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
+#### `UNITY_SHORTHAND_AS_NONE`
-             memory footprint will be compared byte by byte. Directly placing
+
-             constant numbers like `456` as expected values will cause errors.
+These options give you control of the `TEST_ASSERT_EQUAL` and the `TEST_ASSERT_NOT_EQUAL` shorthand assertions.
-  - AS_RAW - Unity assumes that you can compare the two values using `==` and `!=`
+Historically, Unity treated the former as an alias for an integer comparison.
-             and will do so. No details are given about mismatches, because it
+It treated the latter as a direct comparison using `!=`.
-             doesn't really know what type it's dealing with.
+This asymmetry was confusing, but there was much disagreement as to how best to treat this pair of assertions.
-  - AS_NONE - Unity will disallow the use of these shorthand macros altogether,
+These four options will allow you to specify how Unity will treat these assertions.
-             insisting that developers choose a more descriptive option.
+
 - AS INT - the values will be cast to integers and directly compared.
  Arguments 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 memory footprint will be compared byte by byte.
  Directly placing constant numbers like `456` as expected values will cause errors.
 - 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 doesn't really know what type it's dealing with.
 - AS_NONE - Unity will disallow the use of these shorthand macros altogether, insisting that developers choose a more descriptive option.
 #### `UNITY_SUPPORT_VARIADIC_MACROS`
-This will force Unity to support variadic macros when using its own built-in
+This will force Unity to support variadic macros when using its own built-in RUN_TEST macro.
-RUN_TEST macro. This will rarely be necessary. Most often, Unity will automatically
+This will rarely be necessary. Most often, Unity will automatically detect if the compiler supports variadic macros by checking to see if it's C99+ compatible.
-detect if the compiler supports variadic macros by checking to see if it's C99+
+In the event that the compiler supports variadic macros, but is primarily C89 (ANSI), defining this option will allow you to use them.
-compatible. In the event that the compiler supports variadic macros, but is primarily
+This option is also not necessary when using Ceedling or the test runner generator script.
 C89 (ANSI), defining this option will allow you to use them. This option is also not
 necessary when using Ceedling or the test runner generator script.
 ## Getting Into The Guts
-There will be cases where the options above aren't quite going to get everything
+There will be cases where the options above aren't quite going to get everything perfect.
-perfect. They are likely sufficient for any situation where you are compiling
+They are likely sufficient for any situation where you are compiling and executing your tests with a native toolchain (e.g. clang on Mac).
-and executing your tests with a native toolchain (e.g. clang on Mac). These
+These options may even get you through the majority of cases encountered in working with a target simulator run from your local command line.
-options may even get you through the majority of cases encountered in working
+But especially if you must run your test suite on your target hardware, your Unity configuration will
-with a target simulator run from your local command line. But especially if you
+require special help.
-must run your test suite on your target hardware, your Unity configuration will
+This special help will usually reside in one of two places: the `main()` function or the `RUN_TEST` macro.
-require special help. This special help will usually reside in one of two
+Let's look at how these work.
 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.
-Each test module is compiled and run on its own, separate from the other test
+This `main` function will need to contain whatever code is necessary to initialize your system to a workable state.
-files in your project. Each test file, therefore, has a `main` function. This
+This is particularly true for situations where you must set up a memory map or initialize a communication channel for the output of your test results.
 `main` function will need to contain whatever code is necessary to initialize
 your system to a workable state. This is particularly true for situations where
 you must set up a memory map or initialize a communication channel for the
 output of your test results.
 A simple main function looks something like this:
@@ -504,26 +451,22 @@ int main(void) {
 }
 ```
-You can see that our main function doesn't bother taking any arguments. For our
+You can see that our main function doesn't bother taking any arguments.
-most barebones case, we'll never have arguments because we just run all the
+For our most barebones case, we'll never have arguments because we just run all the tests each time.
-tests each time. Instead, we start by calling `UNITY_BEGIN`. We run each test
+Instead, we start by calling `UNITY_BEGIN`.
-(in whatever order we wish). Finally, we call `UNITY_END`, returning its return
+We run each test (in whatever order we wish).
-value (which is the total number of failures).
+Finally, we call `UNITY_END`, returning its return value (which is the total number of failures).
-It should be easy to see that you can add code before any test cases are run or
+It should be easy to see that you can add code before any test cases are run or after all the test cases have completed.
-after all the test cases have completed. This allows you to do any needed
+This allows you to do any needed system-wide setup or teardown that might be required for your special circumstances.
 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 case function.
-The `RUN_TEST` macro is called with each test case function. Its job is to
+This includes catching failures, calling the test module's `setUp()` and `tearDown()` functions, and calling `UnityConcludeTest()`.
-perform whatever setup and teardown is necessary for executing a single test
+If using CMock or test coverage, there will be additional stubs in use here.
-case function. This includes catching failures, calling the test module's
+A simple minimalist RUN_TEST macro looks something like this:
 `setUp()` and `tearDown()` functions, and calling `UnityConcludeTest()`. If
 using CMock or test coverage, there will be additional stubs in use here. A
 simple minimalist RUN_TEST macro looks something like this:
 ```C
 #define RUN_TEST(testfunc) \
@@ -537,27 +480,26 @@ simple minimalist RUN_TEST macro looks something like this:
    UnityConcludeTest();
 ```
-So that's quite a macro, huh? It gives you a glimpse of what kind of stuff Unity
+So that's quite a macro, huh?
-has to deal with for every single test case. For each test case, we declare that
+It gives you a glimpse of what kind of stuff Unity has to deal with for every single test case.
-it is a new test. Then we run `setUp` and our test function. These are run
+For each test case, we declare that it is a new test.
-within a `TEST_PROTECT` block, the function of which is to handle failures that
+Then we run `setUp` and our test function.
-occur during the test. Then, assuming our test is still running and hasn't been
+These are run within a `TEST_PROTECT` block, the function of which is to handle failures that occur during the test.
-ignored, we run `tearDown`. No matter what, our last step is to conclude this
+Then, assuming our test is still running and hasn't been ignored, we run `tearDown`.
-test before moving on to the next.
+No matter what, our last step is to conclude this test before moving on to the next.
 Let's say you need to add a call to `fsync` to force all of your output data to
 flush to a file after each test. You could easily insert this after your
 `UnityConcludeTest` call. Maybe you want to write an xml tag before and after
 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.
 Let's say you need to add a call to `fsync` to force all of your output data to flush to a file after each test.
 You could easily insert this after your `UnityConcludeTest` call.
 Maybe you want to write an xml tag before and after 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
+The defines and macros in this guide should help you port Unity to just about any C target we can imagine.
-any C target we can imagine. If you run into a snag or two, don't be afraid of
+If you run into a snag or two, don't be afraid of asking for help on the forums.
-asking for help on the forums. We love a good challenge!
+We love a good challenge!
 *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
--- a/docs/UnityGettingStartedGuide.md
+++ b/docs/UnityGettingStartedGuide.md
@@ -2,123 +2,104 @@
 ## Welcome
-Congratulations. You're now the proud owner of your very own pile of bits! What
+Congratulations.
-are you going to do with all these ones and zeros? This document should be able
+You're now the proud owner of your very own pile of bits!
-to help you decide just that.
+What are you going to do with all these ones and zeros?
 This document should be able to help you decide just that.
-Unity is a unit test framework. The goal has been to keep it small and
+Unity is a unit test framework.
-functional. The core Unity test framework is three files: a single C file and a
+The goal has been to keep it small and functional.
-couple header files. These team up to provide functions and macros to make
+The core Unity test framework is three files: a single C file and a couple header files.
-testing easier.
+These team up to provide functions and macros to make testing easier.
 Unity was designed to be cross-platform. It works hard to stick with C standards
 while still providing support for the many embedded C compilers that bend the
 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.
 Unity was designed to be cross-platform.
 It works hard to stick with C standards while still providing support for the many embedded C compilers that bend the 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
-This document will guide you through all the assertion options provided by
+This document will guide you through all the assertion options provided by Unity.
-Unity. This is going to be your unit testing bread and butter. You'll spend more
+This is going to be your unit testing bread and butter.
-time with assertions than any other part of Unity.
+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
+This document contains an abridged summary of the assertions described in the previous document.
-previous document. It's perfect for printing and referencing while you
+It's perfect for printing and referencing while you familiarize yourself with Unity's options.
 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
+This document is the one to reference when you are going to use Unity with a new target or compiler.
-target or compiler. It'll guide you through the configuration options and will
+It'll guide you through the configuration options and will help you customize your testing experience to meet your needs.
 help you customize your testing experience to meet your needs.
 #### Unity Helper Scripts
-This document describes the helper scripts that are available for simplifying
+This document describes the helper scripts that are available for simplifying your testing workflow.
-your testing workflow. It describes the collection of optional Ruby scripts
+It describes the collection of optional Ruby scripts included in the auto directory of your Unity installation.
-included in the auto directory of your Unity installation. Neither Ruby nor
+Neither Ruby nor these scripts are necessary for using Unity.
-these scripts are necessary for using Unity. They are provided as a convenience
+They are provided as a convenience for those who wish to use them.
 for those who wish to use them.
 #### Unity License
-What's an open source project without a license file? This brief document
+What's an open source project without a license file?
-describes the terms you're agreeing to when you use this software. Basically, we
+This brief document describes the terms you're agreeing to when you use this software.
-want it to be useful to you in whatever context you want to use it, but please
+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.
 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
+If you have obtained Unity through Github or something similar, you might be surprised by just how much stuff you suddenly have staring you in the face.
-surprised by just how much stuff you suddenly have staring you in the face.
+Don't worry, Unity itself is very small.
-Don't worry, Unity itself is very small. The rest of it is just there to make
+The rest of it is just there to make your life easier.
-your life easier. You can ignore it or use it at your convenience. Here's an
+You can ignore it or use it at your convenience.
-overview of everything in the project.
+Here's an overview of everything in the project.
- `src` - This is the code you care about! This folder contains a C file and two
+- `src` - This is the code you care about! This folder contains a C file and two header files.
-header files. These three files _are_ Unity.
+  These three files _are_ Unity.
- `docs` - You're reading this document, so it's possible you have found your way
+- `docs` - You're reading this document, so it's possible you have found your way into this folder already.
-into this folder already. This is where all the handy documentation can be
+  This is where all the handy documentation can be found.
 found.
 - `examples` - This contains a few examples of using Unity.
- `extras` - These are optional add ons to Unity that are not part of the core
+- `extras` - These are optional add ons to Unity that are not part of the core project.
-project. If you've reached us through James Grenning's book, you're going to
+  If you've reached us through James Grenning's book, you're going to want to look here.
-want to look here.
+- `test` - This is how Unity and its scripts are all tested.
- `test` - This is how Unity and its scripts are all tested. If you're just using
+  If you're just using Unity, you'll likely never need to go in here.
-Unity, you'll likely never need to go in here. If you are the lucky team member
+  If you are the lucky team member who gets to port Unity to a new toolchain, this is a good place to verify everything is configured properly.
-who gets to port Unity to a new toolchain, this is a good place to verify
+- `auto` - Here you will find helpful Ruby scripts for simplifying your test workflow.
-everything is configured properly.
+  They are purely optional and are not required to make use of Unity.
 - `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
+Test files are C files.
-module that you want to test. The test file should include unity.h and the
+Most often you will create a single test file for each C module that you want to test.
-header for your C module to be tested.
+The test file should include unity.h and the header for your C module to be tested.
-Next, a test file will include a `setUp()` and `tearDown()` function. The setUp
+Next, a test file will include a `setUp()` and `tearDown()` function.
-function can contain anything you would like to run before each test. The
+The setUp function can contain anything you would like to run before each test.
-tearDown function can contain anything you would like to run after each test.
+The tearDown function can contain anything you would like to run after each test.
-Both functions accept no arguments and return nothing. You may leave either or
+Both functions accept no arguments and return nothing.
-both of these blank if you have no need for them.
+You may leave either or both of these blank if you have no need for them.
-If you're using Ceedling or the test runner generator script, you may leave these off
+If you're using Ceedling or the test runner generator script, you may leave these off completely.
-completely. Not sure? Give it a try. If your compiler complains that it can't
+Not sure?
-find setUp or tearDown when it links, you'll know you need to at least include
+Give it a try.
-an empty function for these.
+If your compiler complains that it can't find setUp or tearDown when it links, you'll know you need to at least include an empty function for these.
-The majority of the file will be a series of test functions. Test functions
+The majority of the file will be a series of test functions.
-follow the convention of starting with the word "test_" or "spec_". You don't HAVE
+Test functions follow the convention of starting with the word "test_" or "spec_".
-to name them this way, but it makes it clear what functions are tests for other
+You don't HAVE to name them this way, but it makes it clear what functions are tests for other developers.
-developers.  Also, the automated scripts that come with Unity or Ceedling will default
+Also, the automated scripts that come with Unity or Ceedling will default to looking for test functions to be prefixed this way.
-to looking for test functions to be prefixed this way. Test functions take no arguments
+Test functions take no arguments and return nothing. All test accounting is handled internally in Unity.
 and return nothing. All test accounting is handled internally in Unity.
 Finally, at the bottom of your test file, you will write a `main()` function.
-This function will call `UNITY_BEGIN()`, then `RUN_TEST` for each test, and
+This function will call `UNITY_BEGIN()`, then `RUN_TEST` for each test, and finally `UNITY_END()`.
-finally `UNITY_END()`.This is what will actually trigger each of those test
+This is what will actually trigger each of those test functions to run, so it is important that each function gets its own `RUN_TEST` call.
 functions to run, so it is important that each function gets its own `RUN_TEST`
 call.
-Remembering to add each test to the main function can get to be tedious. If you
+Remembering to add each test to the main function can get to be tedious.
-enjoy using helper scripts in your build process, you might consider making use
+If you enjoy using helper scripts in your build process, you might consider making use of our handy [generate_test_runner.rb][] script.
-of our handy [generate_test_runner.rb](../auto/generate_test_runner.rb) script.
+This will create the main function and all the calls for you, assuming that you have followed the suggested naming conventions.
-This will create the main function and all the calls for you, assuming that you
+In this case, there is no need for you to include the main function in your test file at all.
 have followed the suggested naming conventions. In this case, there is no need
 for you to include the main function in your test file at all.
 When you're done, your test file will look something like this:
@@ -156,24 +137,29 @@ 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.
+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.
+
 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.
+These macros perform the necessary setup before the test is called and 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
+At these times, TEST_IGNORE can be called.
-returned to the caller of the test, and no failures will be returned.
+Control will immediately be returned to the caller of the test, and no failures will be returned.
 This is useful when your test runners are automatically generated.
 ``` c
@@ -182,25 +168,35 @@ 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.
+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.
 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,44 +204,39 @@ 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,
+This is the single biggest challenge to picking up a new unit testing framework, at least in a language like C or C++.
-at least in a language like C or C++. These languages are REALLY good at getting
+These languages are REALLY good at getting you "close to the metal" (why is the phrase metal? Wouldn't it be more accurate to say "close to the silicon"?).
-you "close to the metal" (why is the phrase metal? Wouldn't it be more accurate
+While this feature is usually a good thing, it can make testing more challenging.
 to say "close to the silicon"?). While this feature is usually a good thing, it
 can make testing more challenging.
-You have two really good options for toolchains. Depending on where you're
+You have two really good options for toolchains.
-coming from, it might surprise you that neither of these options is running the
+Depending on where you're coming from, it might surprise you that neither of these options is running the unit tests on your hardware.
 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,
 - Unit testing isn't System testing. Keep them separate.
-Instead of running your tests on your actual hardware, most developers choose to
+Instead of running your tests on your actual hardware, most developers choose to develop them as native applications (using gcc or MSVC for example) or as applications running on a simulator.
-develop them as native applications (using gcc or MSVC for example) or as
+Either is a good option.
-applications running on a simulator. Either is a good option. Native apps have
+Native apps have the advantages of being faster and easier to set up.
-the advantages of being faster and easier to set up. Simulator apps have the
+Simulator apps have the advantage of working with the same compiler as your target application.
-advantage of working with the same compiler as your target application. The
+The options for configuring these are discussed in the configuration guide.
 options for configuring these are discussed in the configuration guide.
-To get either to work, you might need to make a few changes to the file
+To get either to work, you might need to make a few changes to the file containing your register set (discussed later).
 containing your register set (discussed later).
-In either case, a test is built by linking unity, the test file, and the C
+In either case, a test is built by linking unity, the test file, and the C file(s) being tested.
-file(s) being tested. These files create an executable which can be run as the
+These files create an executable which can be run as the test set for that module.
-test set for that module. Then, this process is repeated for the next test file.
+Then, this process is repeated for the next test file.
-This flexibility of separating tests into individual executables allows us to
+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!
 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][]*
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[generate_test_runner.rb]: ../auto/generate_test_runner.rb
 [ThrowTheSwitch.org]: https://throwtheswitch.org
--- a/docs/UnityHelperScriptsGuide.md
+++ b/docs/UnityHelperScriptsGuide.md
@@ -3,30 +3,25 @@
 ## With a Little Help From Our Friends
 Sometimes what it takes to be a really efficient C programmer is a little non-C.
-The Unity project includes a couple of Ruby scripts for making your life just a tad
+The Unity project includes a couple of Ruby scripts for making your life just a tad easier.
-easier. They are completely optional. If you choose to use them, you'll need a
+They are completely optional.
-copy of Ruby, of course. Just install whatever the latest version is, and it is
+If you choose to use them, you'll need a copy of Ruby, of course.
-likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
+Just install whatever the latest version is, and it is likely to work. You can find Ruby at [ruby-lang.org][].
 ### `generate_test_runner.rb`
-Are you tired of creating your own `main` function in your test file? Do you
+Are you tired of creating your own `main` function in your test file?
-keep forgetting to add a `RUN_TEST` call when you add a new test case to your
+Do you keep forgetting to add a `RUN_TEST` call when you add a new test case to your suite?
-suite? Do you want to use CMock or other fancy add-ons but don't want to figure
+Do you want to use CMock or other fancy add-ons but don't want to figure out how to create your own `RUN_TEST` macro?
 out how to create your own `RUN_TEST` macro?
 Well then we have the perfect script for you!
-The `generate_test_runner` script processes a given test file and automatically
+The `generate_test_runner` script processes a given test file and automatically creates a separate test runner file that includes ?main?to execute the test cases within the scanned test file.
-creates a separate test runner file that includes ?main?to execute the test
+All you do then is add the generated runner to your list of files to be compiled and linked, and presto you're done!
 cases within the scanned test file. All you do then is add the generated runner
 to your list of files to be compiled and linked, and presto you're done!
-This script searches your test file for void function signatures having a
+This script searches your test file for void function signatures having a function name beginning with "test" or "spec".
-function name beginning with "test" or "spec". It treats each of these
+It treats each of these functions as a test case and builds up a test suite of them.
-functions as a test case and builds up a test suite of them. For example, the
+For example, the following includes three test cases:
 following includes three test cases:
 ```C
 void testVerifyThatUnityIsAwesomeAndWillMakeYourLifeEasier(void)
@@ -41,32 +36,30 @@ void spec_Function_should_DoWhatItIsSupposedToDo(void) {
 }
 ```
-You can run this script a couple of ways. The first is from the command line:
+You can run this script a couple of ways.
 The first is from the command line:
 ```Shell
 ruby generate_test_runner.rb TestFile.c NameOfRunner.c
 ```
-Alternatively, if you include only the test file parameter, the script will copy
+Alternatively, if you include only the test file parameter, the script will copy the name of the test file and automatically append `_Runner` to the name of the generated file.
-the name of the test file and automatically append `_Runner` to the name of the
+The example immediately below will create TestFile_Runner.c.
 generated file. The example immediately below will create TestFile_Runner.c.
 ```Shell
 ruby generate_test_runner.rb TestFile.c
 ```
-You can also add a [YAML](http://www.yaml.org/) file to configure extra options.
+You can also add a [YAML][] file to configure extra options.
-Conveniently, this YAML file is of the same format as that used by Unity and
+Conveniently, this YAML file is of the same format as that used by Unity and CMock.
-CMock. So if you are using YAML files already, you can simply pass the very same
+So if you are using YAML files already, you can simply pass the very same file into the generator script.
 file into the generator script.
 ```Shell
 ruby generate_test_runner.rb TestFile.c my_config.yml
 ```
-The contents of the YAML file `my_config.yml` could look something like the
+The contents of the YAML file `my_config.yml` could look something like the example below.
-example below. If you're wondering what some of these options do, you're going
+If you're wondering what some of these options do, you're going to love the next section of this document.
 to love the next section of this document.
 ```YAML
 :unity:
@@ -74,23 +67,20 @@ to love the next section of this document.
    - stdio.h
    - microdefs.h
  :cexception: 1
-  :suit_setup: "blah = malloc(1024);"
+  :suite_setup: "blah = malloc(1024);"
  :suite_teardown: "free(blah);"
 ```
-If you would like to force your generated test runner to include one or more
+If you would like to force your generated test runner to include one or more header files, you can just include those at the command line too.
-header files, you can just include those at the command line too. Just make sure
+Just make sure these are _after_ the YAML file, if you are using one:
 these are _after_ the YAML file, if you are using one:
 ```Shell
 ruby generate_test_runner.rb TestFile.c my_config.yml extras.h
 ```
-Another option, particularly if you are already using Ruby to orchestrate your
+Another option, particularly if you are already using Ruby to orchestrate your builds - or more likely the Ruby-based build tool Rake - is requiring this script directly.
-builds - or more likely the Ruby-based build tool Rake - is requiring this
+Anything that you would have specified in a YAML file can be passed to the script as part of a hash.
-script directly. Anything that you would have specified in a YAML file can be
+Let's push the exact same requirement set as we did above but this time through Ruby code directly:
 passed to the script as part of a hash. Let's push the exact same requirement
 set as we did above but this time through Ruby code directly:
 ```Ruby
 require "generate_test_runner.rb"
@@ -103,9 +93,8 @@ options = {
 UnityTestRunnerGenerator.new.run(testfile, runner_name, options)
 ```
-If you have multiple files to generate in a build script (such as a Rakefile),
+If you have multiple files to generate in a build script (such as a Rakefile), you might want to instantiate a generator object with your options and call it to generate each runner afterwards.
-you might want to instantiate a generator object with your options and call it
+Like thus:
 to generate each runner afterwards. Like thus:
 ```Ruby
 gen = UnityTestRunnerGenerator.new(options)
@@ -114,70 +103,54 @@ 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.
 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
+This option specifies an array of file names to be `#include`'d at the top of your runner C file.
-your runner C file. You might use it to reference custom types or anything else
+You might use it to reference custom types or anything else universally needed in your generated runners.
 universally needed in your generated runners.
 ##### `:suite_setup`
 Define this option with C code to be executed _before any_ test cases are run.
-Alternatively, if your C compiler supports weak symbols, you can leave this
+Alternatively, if your C compiler supports weak symbols, you can leave this option unset and instead provide a `void suiteSetUp(void)` function in your test suite.
-option unset and instead provide a `void suiteSetUp(void)` function in your test
+The linker will look for this symbol and fall back to a Unity-provided stub if it is not found.
 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
+Define this option with C code to be executed _after all_ test cases have finished.
-finished.  An integer variable `num_failures` is available for diagnostics.
+An integer variable `num_failures` is available for diagnostics.
-The code should end with a `return` statement; the value returned will become
+The code should end with a `return` statement; the value returned will become the exit code of `main`.
-the exit code of `main`.  You can normally just return `num_failures`.
+You can normally just return `num_failures`.
 Alternatively, if your C compiler supports weak symbols, you can leave this
 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.
 Alternatively, if your C compiler supports weak symbols, you can leave this 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
+This option should be defined if you have the strict order feature enabled in CMock (see CMock documentation).
-CMock (see CMock documentation). This generates extra variables required for
+This generates extra variables required for everything to run smoothly.
-everything to run smoothly. If you provide the same YAML to the generator as
+If you provide the same YAML to the generator as used in CMock's configuration, you've already configured the generator properly.
 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
+This option should be defined if you are mixing C and CPP and want your test runners to automatically include extern "C" support when they are generated.
 runners to automatically include extern "C" support when they are generated.
 ##### `:mock_prefix` and `:mock_suffix`
-Unity automatically generates calls to Init, Verify and Destroy for every file
+Unity automatically generates calls to Init, Verify and Destroy for every file included in the main test file that starts with the given mock prefix and ends with the given mock suffix, file extension not included.
-included in the main test file that starts with the given mock prefix and ends
+By default, Unity assumes a `Mock` prefix and no suffix.
 with the given mock suffix, file extension not included. By default, Unity
 assumes a `Mock` prefix and no suffix.
 ##### `:plugins`
-This option specifies an array of plugins to be used (of course, the array can
+This option specifies an array of plugins to be used (of course, the array can contain only a single plugin).
-contain only a single plugin). This is your opportunity to enable support for
+This is your opportunity to enable support for CException support, which will add a check for unhandled exceptions in each test, reporting a failure if one is detected.
-CException support, which will add a check for unhandled exceptions in each
+To enable this feature using Ruby:
 test, reporting a failure if one is detected. To enable this feature using Ruby:
 ```Ruby
 :plugins => [ :cexception ]
@@ -190,57 +163,47 @@ Or as a yaml file:
  -:cexception
 ```
-If you are using CMock, it is very likely that you are already passing an array
+If you are using CMock, it is very likely that you are already passing an array of plugins to CMock.
-of plugins to CMock. You can just use the same array here. This script will just
+You can just use the same array here.
-ignore the plugins that don't require additional support.
+This script will just ignore the plugins that don't require additional support.
 ##### `:include_extensions`
 This option specifies the pattern for matching acceptable header file extensions.
-By default it will accept hpp, hh, H, and h files. If you need a different combination
+By default it will accept hpp, hh, H, and h files.
-of files to search, update this from the default `'(?:hpp|hh|H|h)'`.
+If you need a different combination of files to search, update this from the default `'(?:hpp|hh|H|h)'`.
 ##### `:source_extensions`
 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
+By default it will accept cpp, cc, C, c, and ino files.
-of files to search, update this from the default `'(?:cpp|cc|ino|C|c)'`.
+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
+A Unity test file contains one or more test case functions.
-pass, fail, or be ignored. Each test file is run individually producing results
+Each test case can pass, fail, or be ignored.
-for its collection of test cases. A given project will almost certainly be
+Each test file is run individually producing results for its collection of test cases.
-composed of multiple test files. Therefore, the suite of tests is comprised of
+A given project will almost certainly be composed of multiple test files.
-one or more test cases spread across one or more test files. This script
+Therefore, the suite of tests is comprised of one or more test cases spread across one or more test files.
-aggregates individual test file results to generate a summary of all executed
+This script aggregates individual test file results to generate a summary of all executed test cases.
-test cases. The output includes how many tests were run, how many were ignored,
+The output includes how many tests were run, how many were ignored, and how many failed. In addition, the output includes a listing of which specific tests were ignored and failed.
-and how many failed. In addition, the output includes a listing of which
+A good example of the breadth and details of these results can be found in the `examples` directory.
-specific tests were ignored and failed. A good example of the breadth and
+Intentionally ignored and failing tests in this project generate corresponding entries in the summary report.
 details of these results can be found in the `examples` directory. Intentionally
 ignored and failing tests in this project generate corresponding entries in the
 summary report.
-If you're interested in other (prettier?) output formats, check into the
+If you're interested in other (prettier?) output formats, check into the [Ceedling][] build tool project that works with Unity and CMock and supports xunit-style xml as well as other goodies.
 Ceedling build tool project (ceedling.sourceforge.net) that works with Unity and
 CMock and supports xunit-style xml as well as other goodies.
-This script assumes the existence of files ending with the extensions
+This script assumes the existence of files ending with the extensions `.testpass` and `.testfail`.
-`.testpass` and `.testfail`.The contents of these files includes the test
+The contents of these files includes the test results summary corresponding to each test file executed with the extension set according to the presence or absence of failures for that test file.
-results summary corresponding to each test file executed with the extension set
+The script searches a specified path for these files, opens each one it finds, parses the results, and aggregates and prints a summary.
-according to the presence or absence of failures for that test file. The script
+Calling it from the command line looks like this:
 searches a specified path for these files, opens each one it finds, parses the
 results, and aggregates and prints a summary. Calling it from the command line
 looks like this:
 ```Shell
 ruby unity_test_summary.rb build/test/
 ```
-You can optionally specify a root path as well. This is really helpful when you
+You can optionally specify a root path as well.
-are using relative paths in your tools' setup, but you want to pull the summary
+This is really helpful when you are using relative paths in your tools' setup, but you want to pull the summary into an IDE like Eclipse for clickable shortcuts.
 into an IDE like Eclipse for clickable shortcuts.
 ```Shell
 ruby unity_test_summary.rb build/test/ ~/projects/myproject/
@@ -274,5 +237,9 @@ OVERALL UNITY TEST SUMMARY
 How convenient is that?
 *Find The Latest of This And More at [ThrowTheSwitch.org][]*
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[ruby-lang.org]: https://ruby-labg.org/
 [YAML]: http://www.yaml.org/
 [Ceedling]: http://www.throwtheswitch.org/ceedling
 [ThrowTheSwitch.org]: https://throwtheswitch.org
--- a/extras/fixture/readme.md
+++ b/extras/fixture/readme.md
@@ -1,29 +1,26 @@
 # Unity Fixtures
-This Framework is an optional add-on to Unity.  By including unity_framework.h in place of unity.h,
+This Framework is an optional add-on to Unity.
-you may now work with Unity in a manner similar to CppUTest.  This framework adds the concepts of 
+By including unity_framework.h in place of unity.h, you may now work with Unity in a manner similar to CppUTest.
-test groups and gives finer control of your tests over the command line.
+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
+This framework is primarily supplied for those working through James Grenning's book on Embedded Test Driven Development, or those coming to Unity from CppUTest.
-Test Driven Development, or those coming to Unity from CppUTest. We should note that using this
+We should note that using this framework glosses over some of the features of Unity, and makes it more difficult to integrate with other testing tools like Ceedling and CMock.
 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
+Fixtures, by default, uses the Memory addon as well.
-follow along with James' book. Using them together is completely optional. You may choose to use 
+This is to make it simple for those trying to follow along with James' book.
-Fixtures without Memory handling by defining `UNITY_FIXTURE_NO_EXTRAS`. It will then stop automatically
+Using them together is completely optional.
-pulling in extras and leave you to do it as desired.
+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
+By default the test executables produced by Unity Fixtures run all tests once, but the behavior can be configured with command-line flags.
-be configured with command-line flags. Run the test executable with the `--help` flag for more
+Run the test executable with the `--help` flag for more information.
 information.
-It's possible to add a custom line at the end of the help message, typically to point to
+It's possible to add a custom line at the end of the help message, typically to point to project-specific or company-specific unit test documentation.
-project-specific or company-specific unit test documentation. Define `UNITY_CUSTOM_HELP_MSG` to
+Define `UNITY_CUSTOM_HELP_MSG` to provide a custom message, e.g.:
 provide a custom message, e.g.:
    #define UNITY_CUSTOM_HELP_MSG "If any test fails see https://example.com/troubleshooting"
--- a/extras/memory/readme.md
+++ b/extras/memory/readme.md
@@ -1,49 +1,42 @@
 # Unity Memory
-This Framework is an optional add-on to Unity.  By including unity.h and then
+This Framework is an optional add-on to Unity.
-unity_memory.h, you have the added ability to track malloc and free calls. This 
+By including unity.h and then unity_memory.h, you have the added ability to track malloc and free calls.
-addon requires that the stdlib functions be overridden by its own defines. These
+This addon requires that the stdlib functions be overridden by its own defines.
-defines will still malloc / realloc / free etc, but will also track the calls
+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.
 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
+Note that this is only useful in situations where a unit is in charge of both the allocation and deallocation of memory.
-the allocation and deallocation of memory. When it is not symmetric, unit testing 
+When it is not symmetric, unit testing can report a number of false failures.
-can report a number of false failures. A more advanced runtime tool is required to
+A more advanced runtime tool is required to track complete system memory handling.
 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
+These must be called at the beginning and end of each test.
-be added to `setUp` and `tearDown` in order to do their job. When using the test
+For simplicity, they can be added to `setUp` and `tearDown` in order to do their job.
-runner generator scripts, these will be automatically added to the runner whenever
+When using the test runner generator scripts, these will be automatically added to the runner whenever unity_memory.h is included.
 unity_memory.h is included.
-## `UnityMalloc_MakeMallocFailAfterCount`
+### `UnityMalloc_MakeMallocFailAfterCount`
-This can be called from the tests themselves. Passing this function a number will
+This can be called from the tests themselves.
-force the reference counter to start keeping track of malloc calls. During that test,
+Passing this function a number will force the reference counter to start keeping track of malloc calls.
-if the number of malloc calls exceeds the number given, malloc will immediately 
+During that test, if the number of malloc calls exceeds the number given, malloc will immediately start returning `NULL`.
-start returning `NULL`. This allows you to test error conditions. Think of it as a 
+This allows you to test error conditions.
-simplified mock.
+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.
 `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
+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).
-manage the memory on its own, then define this. All memory will be handled internally
+Note that this is not a very featureful memory manager, but is sufficient for most testing purposes.
 (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
+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.
 allows you to set the heap size this library will use to manage the memory.
--- a/src/unity.c
+++ b/src/unity.c
@@ -445,7 +445,7 @@ void UnityPrintFloat(const UNITY_DOUBLE input_number)
        /* build up buffer in reverse order */
        digits = 0;
-        while ((n != 0) || (digits < (decimals + 1)))
+        while ((n != 0) || (digits <= decimals))
        {
            buf[digits++] = (char)('0' + n % 10);
            n /= 10;
--- a/src/unity.h
+++ b/src/unity.h
@@ -10,7 +10,7 @@
 #define UNITY_VERSION_MAJOR    2
 #define UNITY_VERSION_MINOR    5
-#define UNITY_VERSION_BUILD    2
+#define UNITY_VERSION_BUILD    4
 #define UNITY_VERSION          ((UNITY_VERSION_MAJOR << 16) | (UNITY_VERSION_MINOR << 8) | UNITY_VERSION_BUILD)
 #ifdef __cplusplus
--- a/src/unity_internals.h
+++ b/src/unity_internals.h
@@ -46,6 +46,20 @@
  #define UNITY_FUNCTION_ATTR(a)    /* ignore */
 #endif
 #ifndef UNITY_NORETURN
  #if defined(__cplusplus)
    #if __cplusplus >= 201103L
      #define UNITY_NORETURN [[ noreturn ]]
    #endif
  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
    #include <stdnoreturn.h>
    #define UNITY_NORETURN noreturn
  #endif
 #endif
 #ifndef UNITY_NORETURN
  #define UNITY_NORETURN UNITY_FUNCTION_ATTR(noreturn)
 #endif
 /*-------------------------------------------------------
 * Guess Widths If Not Specified
 *-------------------------------------------------------*/
@@ -333,7 +347,7 @@ typedef UNITY_FLOAT_TYPE UNITY_FLOAT;
        UnityPrintNumberUnsigned(execTimeMs); \
        UnityPrint(" ms)"); \
        }
-    #elif defined(__unix__)
+    #elif defined(__unix__) || defined(__APPLE__)
      #include <time.h>
      #define UNITY_TIME_TYPE struct timespec
      #define UNITY_GET_TIME(t) clock_gettime(CLOCK_MONOTONIC, &t)
@@ -618,8 +632,8 @@ void UnityAssertNumbersArrayWithin(const UNITY_UINT delta,
                                   const UNITY_FLAGS_T flags);
 #ifndef UNITY_EXCLUDE_SETJMP_H
-void UnityFail(const char* message, const UNITY_LINE_TYPE line) UNITY_FUNCTION_ATTR(noreturn);
+UNITY_NORETURN void UnityFail(const char* message, const UNITY_LINE_TYPE line);
-void UnityIgnore(const char* message, const UNITY_LINE_TYPE line) UNITY_FUNCTION_ATTR(noreturn);
+UNITY_NORETURN void UnityIgnore(const char* message, const UNITY_LINE_TYPE line);
 #else
 void UnityFail(const char* message, const UNITY_LINE_TYPE line);
 void UnityIgnore(const char* message, const UNITY_LINE_TYPE line);
@@ -887,7 +901,7 @@ int UnityTestMatches(void);
 #define UNITY_TEST_ASSERT_INT16_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)   UnityAssertNumbersArrayWithin((UNITY_UINT16)(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_INT16, UNITY_ARRAY_TO_ARRAY)
 #define UNITY_TEST_ASSERT_INT32_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)   UnityAssertNumbersArrayWithin((UNITY_UINT32)(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_INT32, UNITY_ARRAY_TO_ARRAY)
 #define UNITY_TEST_ASSERT_UINT_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)    UnityAssertNumbersArrayWithin(              (delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_UINT, UNITY_ARRAY_TO_ARRAY)
-#define UNITY_TEST_ASSERT_UINT8_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)  UnityAssertNumbersArrayWithin( (UNITY_UINT16)(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_UINT8, UNITY_ARRAY_TO_ARRAY)
+#define UNITY_TEST_ASSERT_UINT8_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)   UnityAssertNumbersArrayWithin((UNITY_UINT16)(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_UINT8, UNITY_ARRAY_TO_ARRAY)
 #define UNITY_TEST_ASSERT_UINT16_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)  UnityAssertNumbersArrayWithin((UNITY_UINT16)(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_UINT16, UNITY_ARRAY_TO_ARRAY)
 #define UNITY_TEST_ASSERT_UINT32_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)  UnityAssertNumbersArrayWithin((UNITY_UINT32)(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_UINT32, UNITY_ARRAY_TO_ARRAY)
 #define UNITY_TEST_ASSERT_HEX8_ARRAY_WITHIN(delta, expected, actual, num_elements, line, message)    UnityAssertNumbersArrayWithin((UNITY_UINT8 )(delta), (UNITY_INTERNAL_PTR)(expected), (UNITY_INTERNAL_PTR)(actual), ((UNITY_UINT32)(num_elements)), (message), (UNITY_LINE_TYPE)(line), UNITY_DISPLAY_STYLE_HEX8, UNITY_ARRAY_TO_ARRAY)