ceedling 0.25.0 → 0.27.0

data/vendor/c_exception/docs/ThrowTheSwitchCodingStandard.md

@@ -0,0 +1,207 @@
+# ThrowTheSwitch.org Coding Standard
+
+Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
+we try to follow these standards to unify our contributors' code into a cohesive
+unit (puns intended). You might find places where these standards aren't
+followed. We're not perfect. Please be polite where you notice these discrepancies
+and we'll try to be polite when we notice yours.
+
+;)
+
+
+## Why Have A Coding Standard?
+
+Being consistent makes code easier to understand. We've made an attempt to keep
+our standard simple because we also believe that we can only expect someone to
+follow something that is understandable. Please do your best.
+
+
+## Our Philosophy
+
+Before we get into details on syntax, let's take a moment to talk about our
+vision for these tools. We're C developers and embedded software developers.
+These tools are great to test any C code, but catering to embedded software has
+made us more tolerant of compiler quirks. There are a LOT of quirky compilers
+out there. By quirky I mean "doesn't follow standards because they feel like
+they have a license to do as they wish."
+
+Our philosophy is "support every compiler we can". Most often, this means that
+we aim for writing C code that is standards compliant (often C89... that seems
+to be a sweet spot that is almost always compatible). But it also means these
+tools are tolerant of things that aren't common. Some that aren't even
+compliant. There are configuration options to override the size of standard
+types. There are configuration options to force Unity to not use certain
+standard library functions. A lot of Unity is configurable and we have worked
+hard to make it not TOO ugly in the process.
+
+Similarly, our tools that parse C do their best. They aren't full C parsers
+(yet) and, even if they were, they would still have to accept non-standard
+additions like gcc extensions or specifying `@0x1000` to force a variable to
+compile to a particular location. It's just what we do, because we like
+everything to Just Work™.
+
+Speaking of having things Just Work™, that's our second philosophy. By that, we
+mean that we do our best to have EVERY configuration option have a logical
+default. We believe that if you're working with a simple compiler and target,
+you shouldn't need to configure very much... we try to make the tools guess as
+much as they can, but give the user the power to override it when it's wrong.
+
+
+## Naming Things
+
+Let's talk about naming things. Programming is all about naming things. We name
+files, functions, variables, and so much more. While we're not always going to
+find the best name for something, we actually put quite a bit of effort into
+finding *What Something WANTS to be Called*™.
+
+When naming things, we more or less follow this hierarchy, the first being the
+most important to us (but we do all four whenever possible):
+1. Readable
+2. Descriptive
+3. Consistent
+4. Memorable
+
+
+#### Readable
+
+We want to read our code. This means we like names and flow that are more
+naturally read. We try to avoid double negatives. We try to avoid cryptic
+abbreviations (sticking to ones we feel are common).
+
+
+#### Descriptive
+
+We like descriptive names for things, especially functions and variables.
+Finding the right name for something is an important endeavor. You might notice
+from poking around our code that this often results in names that are a little
+longer than the average. Guilty. We're okay with a tiny bit more typing if it
+means our code is easier to understand.
+
+There are two exceptions to this rule that we also stick to as religiously as
+possible:
+
+First, while we realize hungarian notation (and similar systems for encoding
+type information into variable names) is providing a more descriptive name, we
+feel that (for the average developer) it takes away from readability and
+therefore is to be avoided.
+
+Second, loop counters and other local throw-away variables often have a purpose
+which is obvious. There's no need, therefore, to get carried away with complex
+naming. We find i, j, and k are better loop counters than loopCounterVar or
+whatnot. We only break this rule when we see that more description could improve
+understanding of an algorithm.
+
+
+#### Consistent
+
+We like consistency, but we're not really obsessed with it. We try to name our
+configuration macros in a consistent fashion... you'll notice a repeated use of
+UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
+remember each macro's details.
+
+
+#### Memorable
+
+Where ever it doesn't violate the above principles, we try to apply memorable
+names. Sometimes this means using something that is simply descriptive, but
+often we strive for descriptive AND unique... we like quirky names that stand
+out in our memory and are easier to search for. Take a look through the file
+names in Ceedling and you'll get a good idea of what we are talking about here.
+Why use preprocess when you can use preprocessinator? Or what better describes a
+module in charge of invoking tasks during releases than release_invoker? Don't
+get carried away. The names are still descriptive and fulfill the above
+requirements, but they don't feel stale.
+
+
+## C and C++ Details
+
+We don't really want to add to the style battles out there. Tabs or spaces?
+How many spaces? Where do the braces go? These are age-old questions that will
+never be answered... or at least not answered in a way that will make everyone
+happy.
+
+We've decided on our own style preferences. If you'd like to contribute to these
+projects (and we hope that you do), then we ask if you do your best to follow
+the same. It will only hurt a little. We promise.
+
+
+#### Whitespace
+
+Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
+power-of-2 number that looks decent on a wide screen. We have no more reason
+than that. We break that rule when we have lines that wrap (macros or function
+arguments or whatnot). When that happens, we like to indent further to line
+things up in nice tidy columns.
+
+```C
+    if (stuff_happened)
+    {
+        do_something();
+    }
+```
+
+
+#### Case
+
+- Files - all lower case with underscores.
+- Variables - all lower case with underscores
+- Macros - all caps with underscores.
+- Typedefs - all caps with underscores. (also ends with _T).
+- Functions - camel cased. Usually named ModuleName_FuncName
+- Constants and Globals - camel cased.
+
+
+#### Braces
+
+The left brace is on the next line after the declaration. The right brace is
+directly below that. Everything in between in indented one level. If you're
+catching an error and you have a one-line, go ahead and to it on the same line.
+
+```C
+    while (blah)
+    {
+        //Like so. Even if only one line, we use braces.
+    }
+```
+
+
+#### Comments
+
+Do you know what we hate? Old-school C block comments. BUT, we're using them
+anyway. As we mentioned, our goal is to support every compiler we can,
+especially embedded compilers. There are STILL C compilers out there that only
+support old-school block comments. So that is what we're using. We apologize. We
+think they are ugly too.
+
+
+## Ruby Details
+
+Is there really such thing as a Ruby coding standard? Ruby is such a free form
+language, it seems almost sacrilegious to suggest that people should comply to
+one method! We'll keep it really brief!
+
+
+#### Whitespace
+
+Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
+nice power-of-2 number that really grooves with Ruby's compact style. We have no
+more reason than that. We break that rule when we have lines that wrap. When
+that happens, we like to indent further to line things up in nice tidy columns.
+
+
+#### Case
+
+- Files - all lower case with underscores.
+- Variables - all lower case with underscores
+- Classes, Modules, etc - Camel cased.
+- Functions - all lower case with underscores
+- Constants - all upper case with underscores
+
+
+## Documentation
+
+Egad. Really? We use markdown and we like pdf files because they can be made to
+look nice while still being portable. Good enough?
+
+
+*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

data/vendor/c_exception/vendor/unity/README.md

@@ -2,7 +2,7 @@ Unity Test API
 ==============
 
 [![Unity Build Status](https://api.travis-ci.org/ThrowTheSwitch/Unity.png?branch=master)](https://travis-ci.org/ThrowTheSwitch/Unity)
-__Copyright (c) 2007 - 2014 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
+__Copyright (c) 2007 - 2017 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
 
 Running Tests
 -------------
@@ -41,13 +41,13 @@ Example:
 
     main()
     {
-        if (TEST_PROTECT() == 0)
+        if (TEST_PROTECT())
         {
             MyTest();
         }
     }
 
-If MyTest calls `TEST_ABORT`, program control will immediately return to `TEST_PROTECT` with a non-zero return value.
+If MyTest calls `TEST_ABORT`, program control will immediately return to `TEST_PROTECT` with a return value of zero.
 
 
 Unity Assertion Summary
@@ -109,6 +109,18 @@ Compares two integers for equality and display errors as hexadecimal.  Like the
 you can specify the size... here the size will also effect how many nibbles are shown (for example, `HEX16`
 will show 4 nibbles).
 
+    TEST_ASSERT_EQUAL(expected, actual)
+
+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
+size specific variants.
+
+Arrays
+------
+
     _ARRAY
 
 You can append `_ARRAY` to any of these macros to make an array comparison of that type.  Here you will
@@ -117,15 +129,12 @@ additional argument which is the number of elements to compare.  For example:
 
     TEST_ASSERT_EQUAL_HEX8_ARRAY(expected, actual, elements)
 
-    TEST_ASSERT_EQUAL(expected, actual)
-
-Another way of calling TEST_ASSERT_EQUAL_INT
-
-    TEST_ASSERT_INT_WITHIN(delta, expected, actual)
+    _EACH_EQUAL
 
-Asserts that the actual value is within plus or minus delta of the expected value.  This also comes in
-size specific variants.
+Another array comparison option is to check that EVERY element of an array is equal to a single expected
+value. You do this by specifying the EACH_EQUAL macro. For example:
 
+    TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)
 
 Numerical Assertions: Bitwise
 -----------------------------

data/vendor/c_exception/vendor/unity/auto/colour_prompt.rb

@@ -4,63 +4,62 @@
 #   [Released under MIT License. Please refer to license.txt for details]
 # ==========================================
 
-if RUBY_PLATFORM =~/(win|w)32$/
-	begin
-		require 'Win32API'
-	rescue LoadError
-		puts "ERROR! \"Win32API\" library not found"
-		puts "\"Win32API\" is required for colour on a windows machine"
-		puts "  try => \"gem install Win32API\" on the command line"
-		puts
-	end
-	# puts
+if RUBY_PLATFORM =~ /(win|w)32$/
+  begin
+    require 'Win32API'
+  rescue LoadError
+    puts 'ERROR! "Win32API" library not found'
+    puts '"Win32API" is required for colour on a windows machine'
+    puts '  try => "gem install Win32API" on the command line'
+    puts
+  end
+  # puts
   # puts 'Windows Environment Detected...'
-	# puts 'Win32API Library Found.'
-	# puts
+  # puts 'Win32API Library Found.'
+  # puts
 end
 
 class ColourCommandLine
   def initialize
-    if RUBY_PLATFORM =~/(win|w)32$/
-      get_std_handle = Win32API.new("kernel32", "GetStdHandle", ['L'], 'L')
-      @set_console_txt_attrb =
-        Win32API.new("kernel32","SetConsoleTextAttribute",['L','N'], 'I')
-      @hout = get_std_handle.call(-11)
-    end
+    return unless RUBY_PLATFORM =~ /(win|w)32$/
+    get_std_handle = Win32API.new('kernel32', 'GetStdHandle', ['L'], 'L')
+    @set_console_txt_attrb =
+      Win32API.new('kernel32', 'SetConsoleTextAttribute', %w(L N), 'I')
+    @hout = get_std_handle.call(-11)
   end
 
   def change_to(new_colour)
-    if RUBY_PLATFORM =~/(win|w)32$/
-      @set_console_txt_attrb.call(@hout,self.win32_colour(new_colour))
+    if RUBY_PLATFORM =~ /(win|w)32$/
+      @set_console_txt_attrb.call(@hout, win32_colour(new_colour))
     else
-	  	"\033[30;#{posix_colour(new_colour)};22m"
-	 	end
+      "\033[30;#{posix_colour(new_colour)};22m"
+    end
   end
 
   def win32_colour(colour)
     case colour
-      when :black then 0
-      when :dark_blue then 1
-      when :dark_green then 2
-      when :dark_cyan then 3
-      when :dark_red then 4
-      when :dark_purple then 5
-      when :dark_yellow, :narrative then 6
-      when :default_white, :default, :dark_white then 7
-      when :silver then 8
-      when :blue then 9
-      when :green, :success then 10
-      when :cyan, :output then 11
-      when :red, :failure then 12
-      when :purple then 13
-      when :yellow then 14
-      when :white then 15
-      else
-        0
+    when :black then 0
+    when :dark_blue then 1
+    when :dark_green then 2
+    when :dark_cyan then 3
+    when :dark_red then 4
+    when :dark_purple then 5
+    when :dark_yellow, :narrative then 6
+    when :default_white, :default, :dark_white then 7
+    when :silver then 8
+    when :blue then 9
+    when :green, :success then 10
+    when :cyan, :output then 11
+    when :red, :failure then 12
+    when :purple then 13
+    when :yellow then 14
+    when :white then 15
+    else
+      0
     end
   end
 
-	def posix_colour(colour)
+  def posix_colour(colour)
     # ANSI Escape Codes - Foreground colors
     # | Code | Color                     |
     # | 39   | Default foreground color  |
@@ -81,35 +80,39 @@ class ColourCommandLine
     # | 96   | Light cyan                |
     # | 97   | White                     |
 
-	  case colour
-      when :black then 30
-      when :red, :failure then 31
-      when :green, :success then 32
-			when :yellow then 33
-      when :blue, :narrative then 34
-      when :purple, :magenta then 35
-      when :cyan, :output then 36
-      when :white, :default_white then 37
-      when :default then 39
-      else
-        39
+    case colour
+    when :black then 30
+    when :red, :failure then 31
+    when :green, :success then 32
+    when :yellow then 33
+    when :blue, :narrative then 34
+    when :purple, :magenta then 35
+    when :cyan, :output then 36
+    when :white, :default_white then 37
+    when :default then 39
+    else
+      39
     end
   end
 
   def out_c(mode, colour, str)
     case RUBY_PLATFORM
-			when /(win|w)32$/
-			  change_to(colour)
-				 $stdout.puts str if mode == :puts
-				 $stdout.print str if mode == :print
-			  change_to(:default_white)
-			else
-				$stdout.puts("#{change_to(colour)}#{str}\033[0m") if mode == :puts
-				$stdout.print("#{change_to(colour)}#{str}\033[0m") if mode == :print
-		end
+    when /(win|w)32$/
+      change_to(colour)
+      $stdout.puts str if mode == :puts
+      $stdout.print str if mode == :print
+      change_to(:default_white)
+    else
+      $stdout.puts("#{change_to(colour)}#{str}\033[0m") if mode == :puts
+      $stdout.print("#{change_to(colour)}#{str}\033[0m") if mode == :print
+    end
   end
 end # ColourCommandLine
 
-def colour_puts(role,str)  ColourCommandLine.new.out_c(:puts, role, str)  end
-def colour_print(role,str) ColourCommandLine.new.out_c(:print, role, str) end
+def colour_puts(role, str)
+  ColourCommandLine.new.out_c(:puts, role, str)
+end
 
+def colour_print(role, str)
+  ColourCommandLine.new.out_c(:print, role, str)
+end

data/vendor/c_exception/vendor/unity/auto/colour_reporter.rb

@@ -2,38 +2,38 @@
 #   Unity Project - A Test Framework for C
 #   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
 #   [Released under MIT License. Please refer to license.txt for details]
-# ========================================== 
+# ==========================================
 
 require "#{File.expand_path(File.dirname(__FILE__))}/colour_prompt"
 
 $colour_output = true
 
 def report(message)
-  if not $colour_output
+  if !$colour_output
     $stdout.puts(message)
   else
-    message = message.join('\n') if (message.class == Array)
+    message = message.join('\n') if message.class == Array
     message.each_line do |line|
       line.chomp!
-      colour = case(line)
-        when /(?:total\s+)?tests:?\s+(\d+)\s+(?:total\s+)?failures:?\s+\d+\s+Ignored:?/i
-          ($1.to_i == 0) ? :green : :red
-        when /PASS/
-          :green
-        when /^OK$/
-          :green
-        when /(?:FAIL|ERROR)/
-          :red
-        when /IGNORE/
-          :yellow
-        when /^(?:Creating|Compiling|Linking)/
-          :white
-        else
-          :silver
-      end
+      colour = case line
+               when /(?:total\s+)?tests:?\s+(\d+)\s+(?:total\s+)?failures:?\s+\d+\s+Ignored:?/i
+                 Regexp.last_match(1).to_i.zero? ? :green : :red
+               when /PASS/
+                 :green
+               when /^OK$/
+                 :green
+               when /(?:FAIL|ERROR)/
+                 :red
+               when /IGNORE/
+                 :yellow
+               when /^(?:Creating|Compiling|Linking)/
+                 :white
+               else
+                 :silver
+               end
       colour_puts(colour, line)
     end
   end
   $stdout.flush
   $stderr.flush
-end
+end