ceedling 0.9.0 → 1.0.1

data/vendor/c_exception/test/support/CExceptionConfig.h

@@ -0,0 +1,53 @@
+/* =========================================================================
+    CException - Simple Exception Handling in C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-24 Mark VanderVoord
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#ifndef _EXCEPTION_H
+#define _EXCEPTION_H
+
+#include "unity.h"
+
+extern volatile int TestingTheFallback;
+extern volatile int TestingTheFallbackId;
+
+//Optionally define the exception type (something like an int which can be directly assigned)
+#define CEXCEPTION_T    int
+
+// Optionally define the reserved value representing NO EXCEPTION
+#define CEXCEPTION_NONE (1234)
+
+// Optionally define a special handler for unhandled exceptions
+#define CEXCEPTION_NO_CATCH_HANDLER(id)             \
+{                                                   \
+    if (!TestingTheFallback)                        \
+    {                                               \
+        TEST_FAIL_MESSAGE("Unexpected Exception!"); \
+    }                                               \
+    else                                            \
+    {                                               \
+        TestingTheFallbackId = id;                  \
+        TestingTheFallback--;                       \
+    }                                               \
+}
+
+// Multi-Tasking environments will need a couple of macros defined to make this library
+// properly handle  multiple exception stacks.  You will need to include and required
+// definitions, then define the following macros:
+//    EXCEPTION_GET_ID - returns the id of the current task indexed 0 to (numtasks - 1)
+//    EXCEPTION_NUM_ID - returns the number of tasks that might be returned
+//
+// For example, Quadros might include the following implementation:
+#ifndef TEST
+#include "OSAPI.h"
+#define CEXCEPTION_GET_ID    (KS_GetTaskID())
+#define CEXCEPTION_NUM_ID    (NTASKS + 1)
+#endif
+
+//This could be a good place to define/include some error ID's:
+#define ERROR_ID_EVERYTHING_IS_BROKEN  (0x88)
+#define ERROR_ID_ONLY_THIS_IS_BROKEN   (0x77)
+
+#endif // _EXCEPTION_H

data/vendor/cmock/Gemfile

@@ -0,0 +1 @@
+source "http://rubygems.org/"

data/vendor/cmock/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/vendor/cmock/README.md

@@ -0,0 +1,55 @@
+CMock ![CI](https://github.com/ThrowTheSwitch/CMock/workflows/CI/badge.svg)
+=====
+
+CMock is a mock and stub generator and runtime for unit testing C. It's been designed
+to work smoothly with Unity Test, another of the embedded-software testing tools 
+developed by ThrowTheSwitch.org. CMock automagically parses your C headers and creates
+useful and usable mock interfaces for unit testing. Give it a try!
+
+If you don't care to manage unit testing builds yourself, consider checking out Ceedling, 
+a test-centered build manager for unit testing C code.
+
+ - [Known Issues](docs/CMockKnownIssues.md)
+ - [Change Log](docs/CMockChangeLog.md)
+
+Getting Started
+===============
+
+Your first step is to get yourself a copy of CMock. There are a number of ways to do this:
+
+1. If you're using Ceedling, there is no need to install CMock. It will handle it for you.
+
+2. The simplest way is to grab it off github. The Github method looks something like this:
+
+    > git clone --recursive https://github.com/throwtheswitch/cmock.git
+
+3. You can also grab the `zip` file from github. If you do this, you'll also need to grab yourself a
+copy of Unity and CException, because github unfortunately doesn't bake dependencies into the zip
+files. 
+
+Contributing to this Project
+============================
+
+If you plan to help with the development of CMock (or just want to verify that it can
+perform its self tests on your system) then you can grab its self-testing dependencies, 
+then run its self-tests:
+
+    > cd cmock
+    > bundle install   # Ensures you have all RubyGems needed
+    > cd test
+    > rake             # Run all CMock self tests
+
+Before working on this project, you're going to want to read our guidelines on 
+[contributing](docs/CONTRIBUTING.md). 
+
+API Documentation
+=================
+
+* Not sure what you're doing?
+	* [View docs/CMock_Summary.md](docs/CMock_Summary.md)
+* Interested in our MIT license?
+	* [View docs/license.txt](LICENSE.txt)
+* Are there examples?
+	* They are all in [/examples](examples/)
+* Any other resources to check out?
+	* Definitely! Check out our developer portal on [ThrowTheSwitch.org](http://throwtheswitch.org)

data/vendor/cmock/cmock.gemspec

@@ -0,0 +1,34 @@
+# -*- encoding: utf-8 -*-
+$LOAD_PATH << File.expand_path(File.join(File.dirname(__FILE__), 'lib'))
+require "lib/cmock_version"
+require 'date'
+
+Gem::Specification.new do |s|
+  s.name        = "cmock"
+  s.version     = CMockVersion::GEM
+  s.platform    = Gem::Platform::RUBY
+  s.authors     = ["Mark VanderVoord", "Michael Karlesky", "Greg Williams"]
+  s.email       = ["mark@vandervoord.net", "michael@karlesky.net", "barney.williams@gmail.com"]
+  s.homepage    = "http://throwtheswitch.org/cmock"
+  s.summary     = "CMock is a mocking framework for C unit testing. It's a member of the ThrowTheSwitch.org family of tools."
+  s.description = <<-DESC
+CMock is a mocking framework for C unit testing. It accepts header files and generates mocks automagically for you.
+  DESC
+  s.licenses    = ['MIT']
+
+  s.metadata = {
+    "homepage_uri"      => s.homepage,
+    "bug_tracker_uri"   => "https://github.com/ThrowTheSwitch/CMock/issues",
+    "documentation_uri" => "https://github.com/ThrowTheSwitch/CMock/blob/master/docs/CMock_Summary.md",
+    "mailing_list_uri"  => "https://groups.google.com/forum/#!categories/throwtheswitch/cmock",
+    "source_code_uri"   => "https://github.com/ThrowTheSwitch/CMock"
+  }
+  
+  s.required_ruby_version = ">= 3.0.0"
+
+  s.files      += Dir['**/*']
+  s.test_files  = Dir['test/**/*']
+  s.executables = ['lib/cmock.rb']
+
+  s.require_paths = ["lib"]
+end

data/vendor/cmock/config/production_environment.rb

@@ -0,0 +1,13 @@
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+# Setup our load path:
+[
+  'lib'
+].each do |dir|
+  $:.unshift(File.join("#{__dir__}//..//", dir))
+end

data/vendor/cmock/config/test_environment.rb

@@ -0,0 +1,17 @@
+# =========================================================================
+#   CMock - Automatic Mock Generation for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+# Setup our load path:
+[
+  './lib',
+  './vendor/behaviors/lib',
+  './vendor/hardmock/lib',
+  './vendor/unity/auto/',
+  './test/system/'
+].each do |dir|
+  $:.unshift(File.join(File.expand_path("#{File.dirname(__FILE__)}//..//"), dir))
+end

data/vendor/cmock/docs/CMockChangeLog.md

@@ -0,0 +1,166 @@
+# CMock - Change Log
+
+## A Note
+
+This document captures significant features and fixes to the CMock project core source files 
+and scripts. More detail can be found in the history on Github. 
+
+This project is now tracking changes in more detail. Previous releases get less detailed as
+we move back in histroy. 
+
+Prior to 2012, the project was hosted on SourceForge.net
+Prior to 2008, the project was an internal project and not released to the public.
+
+## Log
+
+### CMock 2.6.0 (January 2025)
+
+New Features:
+
+  - Reintroduced option to run CMock without setjmp (slightly limited)
+  - Significant speed improvements to parsing
+
+Significant Bugfixes:
+
+  - Make return-thru-pointer calls const
+  - Fix handling of static inlines
+  - Fix some situations where parenthetical statements were misinterpreted as functions
+  - Fix error in skeleton creation
+  - Improvements towards making generated code fully C-compliant and warning free
+
+Other:
+
+  - Improve error message wording where possible
+  - Improve documentation
+  - Updated to Ruby 3.0 - 3.3
+  - Reintroduce matrix testing across multiple Ruby versions
+
+### CMock 2.5.3 (January 2021)
+
+New Features:
+
+  - Support mocks in sub-folders
+  - Improved handling of static and inline functions
+  - Stateless Ignore plugin added
+
+Significant Bugfixes:
+
+  - Allow setting values to empty at command prompt
+  - Improvements towards making generated code fully C-compliant and warning free
+
+Other:
+  
+  - Really basic mocking of cpp files (like C files with extern C)
+
+### CMock 2.5.2 (May 2020)
+
+Significant Bugfixes:
+
+  - Fix whitespace errors
+  - Fix Stop Ignore
+
+### CMock 2.5.1 (April 2020)
+
+New Features:
+
+  - Add StopIgnore function to Ignore Plugin
+  - Add ability to generate skeleton from a header.
+  - Inline functions now have option to remove and mock (with Ceedling's help)
+
+Significant Bugfixes:
+
+  - Convert internal handling of bools to chars from ints for memory savings
+  - Convert CMOCK_MEM_INDEX_TYPE default type to size_t 
+  - Switch to old-school comments for supporting old C compilers
+  - Significant improvements to handling array length expressions
+  - Significant improvements to our "C parser"
+  - Added brace-pair counting to improve parsing
+  - Fixed error when `:unity_helper_path` is relative
+
+Other:
+
+ - Improve documentation
+ - Optimize speed for pass case, particularly in `_verify()` functions
+ - Increased depth of unit and system tests
+
+### CMock 2.5.0 (October 2019)
+
+New Features:
+
+  - New memory bounds checking.
+  - New memory alignment algorithm.
+  - Add `ExpectAnyArgs` plugin
+  - Divided `CVallback` from `Stub` functionality so we can do both.
+  - Improved wording of failure messages.
+  - Added `:treat_as_array` configuration option
+
+Significant Bugfixes:
+
+  - Fixed bug where `CMock_Guts_MemBytesUsed()` didn't always return `0` before usage
+  - Fixed bug which sometimes got `CMOCK_MEM_ALIGN` wrong
+  - Fixed bug where `ExpectAnyArgs` was generated for functions without args.
+  - Better handling of function pointers
+
+Other:
+
+  - `void*` now tested as bytewise array comparison.
+  - Documentation fixes, particularly to examples.
+  - Added `resetTest` to documentation
+  - New handling of messaging to greatly reduce memory footprint
+
+### CMock 2.4.6 (November 2017)
+
+Significant Bugfixes:
+
+  - Fixed critical bug when running dynamic memory.
+
+### CMock 2.4.5 (September 2017)
+
+New Features:
+
+  - Simple threading of mocks introduced.
+
+Significant Bugfixes:
+  
+  - Improvements to handling pointer const arguments.
+  - Treat `char*` separately from an array of bytes.
+  - Fixed handling of string arguments.
+  - Preserve `const` in all arguments.
+  - Fixed race condition when `require`ing plugins
+
+Other:
+
+  - Expand docs on `strict_mock_calling`
+
+### CMock 2.4.4 (April 2017)
+
+New Features:
+
+  - Add `INCLUDE_PATH` option for specifying source
+
+Significant Bugfixes:
+
+  - Parsing improvements related to braces, brackets, and parenthesis
+  - `ReturnThruPtr` checks destination not null before copying data.
+  - Stub overrides Ignore
+  - Improvements to guessing memory alignment based on datatypes
+
+Other:
+
+  - Reorganize testing into subdirectory to not clutter for new users
+  - Docs switching to markdown from pdf
+
+### CMock 2.4.3 (October 2016)
+
+New Features:
+
+  - Support multiple helper header files.
+  - Add ability to use `weak` symbols if compiler supports it
+  - Add mock suffix option in addition to mock prefix.
+
+Significant Bugfixes:
+
+  - Improved UNICODE support
+
+
+

data/vendor/cmock/docs/CMockKnownIssues.md

@@ -0,0 +1,13 @@
+# CMock - Known Issues
+
+## A Note
+
+This project will do its best to keep track of significant bugs that might effect your usage of this
+project and its supporting scripts. A more detailed and up-to-date list for cutting edge CMock can
+be found on our Github repository.
+
+## Issues
+
+  - Able to parse most C header files without preprocessor needs, but when handling headers with significant preprocessor usage (#ifdefs, etc), it can get confused
+  - Multi-dimensional arrays currently simplified to single dimensional arrays of the full size
+  - Incomplete support for VarArgs

data/vendor/cmock/docs/CMock_ArgumentValidation.md

@@ -0,0 +1,274 @@
+CMock: Argument Validation
+==========================
+
+Much of the power of CMock comes from its ability to automatically 
+validate that the arguments passed to mocked functions are the 
+values that were expected to be passed. CMock puts a lot of effort
+into guessing how the user would most like to see those values 
+compared, and then represented when failures are encountered.
+
+Like Unity, CMock follows a philosophy of making its best guesses,
+and then allowing the user to explicity specify any features that 
+they would like to change or customize.
+
+Option 1: Common Types
+----------------------
+
+First, if you're dealing with C's standard types, there is nothing
+further you need to do. CMock will choose an appropriate assertion
+from Unity's list of assertions and will perform the comparison and
+display using that. For example, if you specify a `short`, then it's 
+very likely CMock will compare using `TEST_ASSERT_EQUAL_INT16`. For
+unsigned values, it assumes you'd like them displayed in hex. Are you
+interested in comparing a `const char*`? That would be Unity's 
+string comparison. 
+
+What if you have some other type of pointer? If you've instructed
+CMock to compare pointers, it'll use `TEST_ASSERT_EQUAL_PTR`. 
+Otherwise it'll use dereference the value being pointed at and 
+compare that for you. (Read more about the Array plugin for more
+details on how this all works). The TYPE being pointed to follows the
+same rules as the those above... so if they're common types, for example 
+`unsigned char*`, then CMock will choose to compare using the 
+logical assertion (in this case `TEST_ASSERT_EQUAL_HEX8`).
+
+A quick note about floating point types: we're calling the assertions
+`TEST_ASSERT_EQUAL_FLOAT` (for example), but don't worry... these 
+assertions are actually checking to make sure that the values are
+"incredibly close" to the desired value instead of identical. This
+is because many numbers can be represented in multiple ways when
+using floating point. These differences are out of the control of 
+the user, for the most part. You can ready more about this in the
+Unity documentation if you're interested in the details.
+
+Option 1b: The Fallback Plan
+----------------------------
+
+So what happens when CMock doesn't recognize the type being used?
+This will happen for any custom types being used. What constitutes
+a custom type?
+
+  - You've used `#define` to create an alias for a standard type
+  - You've used `typedef` to create an alias for a standard type
+  - You've created an `enum` type
+  - You've created a `union` type
+  - You've created a `struct` type
+  - You're working with a function pointer
+
+ When CMock doesn't recognize the type as a standard type, (and 
+ assuming you don't have a better option specified, as any of the
+ options below), it will fall back to performing a memory 
+ comparison using `TEST_ASSERT_EQUAL_MEMORY`. For the most part,
+ this is effective, but the reported failures are not terribly
+ descriptive.
+
+ **WARNING:** There is one important instance where this fallback method
+ doesn't work at all. If the custom type is a `struct` and that 
+ struct isn't packed, then it's possible you can get false failures
+ when the unused bytes between fields differ. For an unpacked struct,
+ it's important that you either use option 3 or 4 below, or ignore that
+ particular argument (and possibly test it manually yourself).
+
+Option 2: Treat-As
+------------------
+
+CMock maintains a list of non-standard types which are basically 
+aliases of standard types. For example, a common shorthand for 
+a single-byte unsigned integer might be `u8` or `U8` or `UNIT8`.
+Any of these can simply be mapped to the standard 
+`TEST_ASSERT_EQUAL_HEX8`.
+
+While CMock has its own list of `:treat_as` mappings, you can 
+add your own pairings to this list. This works especially well for
+the following types:
+
+  - aliases of standard types using `#define` or `typedef`
+  - `enum` types (works well as `INT8` or whatever size your enums are)
+  - function pointers often work well as `PTR` comparisons
+  - `union` types sometimes make sense to treat as the largest type... 
+    but this is a judgement call
+
+Option 3: Custom Assertions for Custom Types
+--------------------------------------------
+
+CMock has the ability to use custom assertions, if you form them 
+according to certain specifications. Creating a custom assertion 
+can be a bit of work, But the reward is that, once you've done so,
+you can use those assertions within your own tests AND CMock will
+magically use them within its own mocks.
+
+To accomplish this, we're going tackle multiple steps:
+
+  1. Write a custom assertion function
+  2. Wrap it in a `UNITY_TEST_` macro
+  3. Wrap it in a `TEST_` macro
+  4. Inform CMock that it exists
+
+Let's look at each of those steps in detail:
+
+### Creating a Custom Assertion
+
+A custom assertion is a function which accepts a standard set of 
+inputs, and then uses Unity's assertion macros to verify any details
+required for the types involved. 
+
+The inputs:
+
+  - the `expected` value (as a `const` version of type being verified)
+  - the `actual` value (also as a `const` version of the desired type)
+  - the `line` this function was called from (as type `UNITY_LINE_TYPE`)
+  - an optional `message` to be appended (as type `const char*`)
+
+Inside the function, we use the *internal* versions of Unity's assertions
+to validate any details that need validating.
+
+Let's look at an example! Let's say we have the following type:
+
+```
+typedef struct MyType_t
+{
+    int a;
+    const char* b;
+} MyType;
+```
+
+In our application, the length of `b` is supposed to be specified by `a`,
+and `b` is therefore allowed to have any value (including `0x00`). 
+
+Our custom assertion might look something like this:
+
+```
+void AssertEqualMyType(const MyType expected, const MyType actual, UNITY_LINE_TYPE line, const char* message)
+{
+    //It's common to override the default message with our own 
+    (void)message; 
+
+    // Verify the lengths are the same, or they're clearly not matched
+    UNITY_TEST_ASSERT_EQUAL_INT(expected.a, actual.a, line, "Data length mismatch");
+
+    // Verify we're dealing with actual pointers
+    UNITY_TEST_ASSERT_NOT_NULL(expected.b, line, "Expected value should not be NULL");
+    UNITY_TEST_ASSERT_NOT_NULL(actual.b, line, "Actual value should not be NULL");
+
+    // Verify the string contents
+    UNITY_TEST_ASSERT_EQUAL_MEMORY(expected.b, actual.b, expected.a, line, "Data not equal");
+}
+```
+
+There are a few things to note about this. First, notice we're using the 
+`UNITY_TEST_ASSERT_` assertions? That's because these allow us to pass 
+on the specific line number. Second, notice we override the message with our
+own more helpful messages? You don't need to do this, but anything you can do
+to help a developer find a bug is a good thing.
+
+What if there isn't an assertion that is right for your needs? You can 
+always do whatever operations are necessary yourself, and use `UNITY_TEST_FAIL()`
+directly.
+
+One final note: It's best to only test the things that are hard rules about
+how a type is supposed to work in your system. Anything else should be left to
+the test code.
+
+For example, let's say that in our example above, there are situations where
+it IS valid for the pointers to be `NULL`. Perhaps the pointers are ignored
+completely when the `a` field is `0`. In that case, we could drop those 
+assertions completely, or add logic to only check when necessary.
+
+Similarly, should our assertion check that the length is positive? In this
+case, it's dangerous if it's negative, because the memory check wouldn't like it.
+
+Updating for these concerns:
+
+
+```
+void AssertEqualMyType(const MyType expected, const MyType actual, UNITY_LINE_TYPE line, const char* message)
+{
+    //It's common to override the default message with our own 
+    (void)message; 
+
+    // Verify the lengths are the same, or they're clearly not matched
+    UNITY_TEST_ASSERT_EQUAL_INT(expected.a, actual.a, line, "Data length mismatch");
+
+    // Verify the lengths are non-negative
+    UNITY_TEST_ASSERT_GREATER_OR_EQUAL_INT(0, expected.a, line, "Data length must be positive");
+
+    if (expected.a > 0)
+    {
+        // Verify we're dealing with actual pointers
+        UNITY_TEST_ASSERT_NOT_NULL(expected.b, line, "Expected value should not be NULL");
+        UNITY_TEST_ASSERT_NOT_NULL(actual.b, line, "Actual value should not be NULL");
+
+        // Verify the string contents
+        UNITY_TEST_ASSERT_EQUAL_MEMORY(expected.b, actual.b, expected.a, line, "Data not equal");
+    }
+}
+```
+
+### Wrapping our Assertion in Macros
+
+Once you have a function which does the main work, we *need* to create
+one macro, and there are a number of other macros which are useful to
+create, in order to treat our assertion just like any other Unity 
+assertion.
+
+`#define UNITY_TEST_ASSERT_EQUAL_MyType(e,a,l,m) AssertEqualMyType(e,a,l,m)`
+
+The macro above is the one that CMock is looking for. Notice that it 
+starts with `UNITY_TEST_ASSERT_EQUAL_` followed by the name of our type, 
+*exactly* the way our type is named. The arguments are, in order:
+
+  - `e` - expected value
+  - `a` - actual value
+  - `l` - line number to report
+  - `m` - message to append at the end
+
+If CMock finds a macro that matches this argument list and naming convention,
+then it can automatically use this assertion where needed... all we need to
+do now is tell CMock where to find our custom assertion.
+
+### Informing CMock about our Assertion
+
+In the CMock configuration file, in the `:cmock` or `:unity` sections, 
+there can be an option for `unity_helper_path`. Add the location of your
+new Unity helper file (file with this assertion) to this list.
+
+Done!
+
+**Bonus:** Once you've created a custom assertion, you can use it
+with `:treat_as`, just like any other standard type! This is 
+particularly useful when there is a custom type which is a pointer
+to a custom type.
+
+For example, let's say you have these types:
+
+```
+typedef struct MY_STRUCT_T_
+{
+    int a;
+    const char* b;
+} MY_STRUCT_T;
+
+typedef MY_STRUCT_T* MY_STRUCT_POINTER_T;
+```
+
+Also, let's assume you've created the following assertion:
+
+```
+UNITY_TEST_ASSERT_EQUAL_MY_STRUCT_T(e,a,l,m)
+```
+
+You can use `:treat_as` like so:
+
+```
+:treat_as:
+  MY_STRUCT_POINTER_T: MY_STRUCT_T*
+```
+
+Option 4: Callback
+------------------
+
+Finally, You can choose to avoid the use of `_Expect` calls altogether
+for challenging types, and use a `Callback` instead. The advantage is that
+you can fill in whichever assertions make sense for that particular test,
+instead of needing to rely on reusable assertions as used elsewhere. 
+Typically, this option is also less work than option 3.