diff options
Diffstat (limited to 'FreeRTOS-Plus/Test/CMock/vendor/c_exception')
16 files changed, 1545 insertions, 0 deletions
diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitattributes b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitattributes new file mode 100644 index 000000000..ad952260b --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitattributes @@ -0,0 +1,30 @@ +* text=auto + +# These files are text and should be normalized (convert crlf to lf) +*.rb text +*.test text +*.c text +*.cpp text +*.h text +*.txt text +*.yml text +*.s79 text +*.bat text +*.xcl text +*.inc text +*.info text +*.md text +makefile text +rakefile text + + +#These files are binary and should not be normalized +*.doc binary +*.odt binary +*.pdf binary +*.ewd binary +*.eww binary +*.dni binary +*.wsdt binary +*.dbgdt binary +*.mac binary diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitignore b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitignore new file mode 100644 index 000000000..c795b054e --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitignore @@ -0,0 +1 @@ +build
\ No newline at end of file diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitmodules b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitmodules new file mode 100644 index 000000000..e69de29bb --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.gitmodules diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.travis.yml b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.travis.yml new file mode 100644 index 000000000..ac313a624 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/.travis.yml @@ -0,0 +1,16 @@ +sudo: required +language: ruby c + +os: + - linux + +rvm: + - "2.3" + - "2.4" + - "2.6" + +install: + - gem install ceedling + +script: + - ceedling clobber test:all diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/Gemfile b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/Gemfile new file mode 100644 index 000000000..0ab41bb5e --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/Gemfile @@ -0,0 +1,4 @@ +source "http://rubygems.org/" + +gem "rake" +gem "test-unit", "~> 2.4" diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/Gemfile.lock b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/Gemfile.lock new file mode 100644 index 000000000..862214260 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/Gemfile.lock @@ -0,0 +1,12 @@ +GEM + remote: http://rubygems.org/ + specs: + rake (12.3.3) + test-unit (2.5.5) + +PLATFORMS + ruby + +DEPENDENCIES + rake + test-unit (~> 2.4) diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/README.md b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/README.md new file mode 100644 index 000000000..53e52ea63 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/README.md @@ -0,0 +1,249 @@ +CException - Lightweight exception library for C +================================================ + +[](https://travis-ci.org/ThrowTheSwitch/CException) + +_This Documentation Is Released Under a Creative Commons 3.0 Attribution Share-Alike License_ + +CException is simple exception handling in C. It is significantly faster than full-blown C++ exception handling +but loses some flexibility. It is portable to any platform supporting `setjmp`/`longjmp`. + +Getting Started +================ + +The simplest way to get started is to just grab the code and pull it into your project: + +``` +git clone https://github.com/throwtheswitch/cexception.git +``` + +If you want to contribute to this project, you'll also need to have Ruby and Ceedling installed to run the unit tests. + +Usage +===== + +### So what's it good for? + +Mostly error handling. Passing errors down a long chain of function calls gets ugly. Sometimes really ugly. +So what if you could just specify certain places where you want to handle errors, and all your errors were +transferred there? Let's try a lame example: + +CException uses C standard library functions setjmp and longjmp to operate. As long as the target system +has these two functions defined, this library should be useable with very little configuration. It even +supports environments where multiple program flows are in use, such as real-time operating systems... +we started this project for use in embedded systems... but it obviously can be used for larger systems too. + +### Error Handling with CException: + +``` +void functionC(void) { + //do some stuff + if (there_was_a_problem) + Throw(ERR_BAD_BREATH); + //this stuff never gets called because of error +} +``` + +There are about a gajillion exception frameworks using a similar setjmp/longjmp method out there... and there +will probably be more in the future. Unfortunately, when we started our last embedded project, all those that +existed either (a) did not support multiple tasks (therefore multiple stacks) or (b) were way more complex +than we really wanted. CException was born. + +Why? +==== + +### It's ANSI C + +...and it beats passing error codes around. + +### You want something simple... + +CException throws a single id. You can define those ID's to be whatever you like. +You might even choose which type that number is for your project. But that's as far as it goes. We weren't interested +in passing objects or structs or strings... just simple error codes. Fast. Easy to Use. Easy to Understand. + +### Performance... + +CException can be configured for single tasking or multitasking. In single tasking, there is +very little overhead past the setjmp/longjmp calls (which are already fast). In multitasking, your only additional +overhead is the time it takes you to determine a unique task id (0 to num_tasks). + +How? +==== + +Code that is to be protected are wrapped in `Try { }` blocks. The code inside the Try block is _protected_, +meaning that if any Throws occur, program control is directly transferred to the start of the Catch block. +The Catch block immediately follows the Try block. It's ignored if no errors have occurred. + +A numerical exception ID is included with Throw, and is passed into the Catch block. This allows you to handle +errors differently or to report which error has occurred... or maybe it just makes debugging easier so you +know where the problem was Thrown. + +Throws can occur from anywhere inside the Try block, directly in the function you're testing or even within +function calls (nested as deeply as you like). There can be as many Throws as you like, just remember that +execution of the guts of your Try block ends as soon as the first Throw is triggered. Once you throw, you're +transferred to the Catch block. A silly example: + +``` +void SillyExampleWhichPrintsZeroThroughFive(void) { + CEXCEPTION_T e; + int i; + while (i = 0; i < 6; i++) { + Try { + Throw(i); + //This spot is never reached + } + Catch(e) { + printf(“%i “, e); + } + } +} +``` + +Limitations +=========== + +This library was made to be as fast as possible, and provide basic exception handling. It is not a full-blown +exception library like C++. Because of this, there are a few limitations that should be observed in order to +successfully utilize this library: + +### Return & Goto + +Do not directly `return` from within a `Try` block, nor `goto` into or out of a `Try` block. +The `Try` macro allocates some local memory and alters a global pointer. These are cleaned up at the +top of the `Catch` macro. Gotos and returns would bypass some of these steps, resulting in memory leaks +or unpredictable behavior. + +### Local Variables + +If (a) you change local (stack) variables within your `Try` block, and (b) wish to make use of the updated +values after an exception is thrown, those variables should be made `volatile`. + +Note that this is ONLY for locals and ONLY when you need access to them after a `Throw`. + +Compilers optimize (and thank goodness they do). There is no way to guarantee that the actual memory +location was updated and not just a register unless the variable is marked volatile. + +### Memory Management + +Memory which is `malloc`'d within a `Try` block is not automatically released when an error is thrown. This +will sometimes be desirable, and othertimes may not. It will be the responsibility of the code you put in +the `Catch` block to perform this kind of cleanup. + +There's just no easy way to track `malloc`'d memory, etc., without replacing or wrapping `malloc` +calls or something like that. This is a lightweight framework, so these options were not desirable. + +CException API +============== + +### `Try { ... }` + +`Try` is a macro which starts a protected block. It MUST be followed by a pair of braces or a single +protected line (similar to an 'if'), enclosing the data that is to be protected. It MUST be followed by +a `Catch` block (don't worry, you'll get compiler errors to let you know if you mess any of that up). + +The `Try` block is your protected block. It contains your main program flow, where you can ignore errors +(other than a quick `Throw` call). You may nest multiple `Try` blocks if you want to handle errors at +multiple levels, and you can even rethrow an error from within a nested `Catch`. + +### `Catch(e) { }` + +`Catch` is a macro which ends the `Try` block and starts the error handling block. The `Catch` block +is executed if and only if an exception was thrown while within the `Try` block. This error was thrown +by a `Throw` call somewhere within `Try` (or within a function called within `Try`, or a function called +by a function called within `Try`... you get the idea.). + +`Catch` receives a single id of type `CEXCEPTION_T` which you can ignore or use to handle the error in +some way. You may throw errors from within Catches, but they will be caught by a `Try` wrapping the `Catch`, +not the one immediately preceeding. + +### `Throw(e)` + +`Throw` is the method used to throw an error. `Throw`s should only occur from within a protected +(`Try`...`Catch`) block, though it may easily be nested many function calls deep without an impact +on performance or functionality. `Throw` takes a single argument, which is an exception id which will be + passed to `Catch` as the reason for the error. If you wish to _re-throw_ an error, this can be done by +calling `Throw(e)` with the error code you just caught. It _IS_ valid to throw from a `Catch` block. + +### `ExitTry()` + +`ExitTry` is a method used to immediately exit your current Try block but NOT treat this as an error. Don't +run the Catch. Just start executing from after the Catch as if nothing had happened. + +Configuration +============= + +CException is a mostly portable library. It has one universal dependency, plus some macros which are required if +working in a multi-tasking environment. + +The standard C library setjmp must be available. Since this is part of the standard library, it's all good. + +If working in a multitasking environment, you need a stack frame for each task. Therefore, you must define +methods for obtaining an index into an array of frames and to get the overall number of id's are required. If +the OS supports a method to retrieve task ID's, and those tasks are number 0, 1, 2... you are in an ideal +situation. Otherwise, a more creative mapping function may be required. Note that this function is likely to +be called twice for each protected block and once during a throw. This is the only added overhead in the system. + +You have options for configuring the library, if the defaults aren't good enough for you. You can add defines +at the command prompt directly. You can always include a configuration file before including `CException.h`. +You can make sure `CEXCEPTION_USE_CONFIG_FILE` is defined, which will force make CException look for +`CExceptionConfig.h`, where you can define whatever you like. However you do it, you can override any or +all of the following: + +### `CEXCEPTION_T` + +Set this to the type you want your exception id's to be. Defaults to an 'unsigned int'. + +### `CEXCEPTION_NONE` + +Set this to a number which will never be an exception id in your system. Defaults to `0x5a5a5a5a`. + +### `CEXCEPTION_GET_ID` + +If in a multi-tasking environment, this should be set to be a call to the function described in #2 above. +It defaults to just return 0 all the time (good for single tasking environments, not so good otherwise). + +### `CEXCEPTION_NUM_ID` + +If in a multi-tasking environment, this should be set to the number of ID's required (usually the number +of tasks in the system). Defaults to 1 (good for single tasking environments or systems where you will only +use this from one task). + +### `CEXCEPTION_NO_CATCH_HANDLER (id)` + +This macro can be optionally specified. It allows you to specify code to be called when a Throw is made +outside of Try...Catch protection. Consider this the emergency fallback plan for when something has gone +terribly wrong. + +### And More! + +You may also want to include any header files which will commonly be needed by the rest of your application +where it uses exception handling here. For example, OS header files or exception codes would be useful. + +Finally, there are some hook macros which you can implement to inject your own target-specific code in +particular places. It is a rare instance where you will need these, but they are here if you need them: + +* `CEXCEPTION_HOOK_START_TRY` - called immediately before the Try block +* `CEXCEPTION_HOOK_HAPPY_TRY` - called immediately after the Try block if no exception was thrown +* `CEXCEPTION_HOOK_AFTER_TRY` - called immediately after the Try block OR before an exception is caught +* `CEXCEPTION_HOOK_START_CATCH` - called immediately before the catch + +Testing +======= + +If you want to validate that CException works with your tools or that it works with your custom +configuration, you may want to run the included test suite. This is the test suite (along with real +projects we've used it on) that we use to make sure that things actually work the way we claim. +The test suite makes use of Ceedling, which uses the Unity Test Framework. It will require a native C compiler. +The example makefile and rakefile both use gcc. + +License +======= + +*This software is licensed under the MIT License: +Copyright (c) 2007-2019 Mark VanderVoord* + +*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._* diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/docs/CException.md b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/docs/CException.md new file mode 100644 index 000000000..bfda613d6 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/docs/CException.md @@ -0,0 +1,332 @@ + +CException +========== + +CException is a basic exception framework for C, suitable for use in +embedded applications. It provides an exception framework similar in +use to C++, but with much less overhead. + + +CException uses C standard library functions `setjmp` and `longjmp` to +operate. As long as the target system has these two functions defined, +this library should be useable with very little configuration. It +even supports environments where multiple program flows are in use, +such as real-time operating systems. + + +There are about a gabillion exception frameworks using a similar +setjmp/longjmp method out there... and there will probably be more +in the future. Unfortunately, when we started our last embedded +project, all those that existed either (a) did not support multiple +tasks (therefore multiple stacks) or (b) were way more complex than +we really wanted. CException was born. + + +*Why use CException?* + + +0. It's ANSI C, and it beats passing error codes around. +1. You want something simple... CException throws a single id. You can + define those ID's to be whatever you like. You might even choose which + type that number is for your project. But that's as far as it goes. + We weren't interested in passing objects or structs or strings... + just simple error codes. +2. Performance... CException can be configured for single tasking or + multitasking. In single tasking, there is very little overhead past + the setjmp/longjmp calls (which are already fast). In multitasking, + your only additional overhead is the time it takes you to determine + a unique task id 0 - num_tasks. + + +For the latest version, go to [ThrowTheSwitch.org](http://throwtheswitch.org) + + +CONTENTS OF THIS DOCUMENT +========================= + +* Usage +* Limitations +* API +* Configuration +* Testing +* License + + +Usage +----- + +Code that is to be protected are wrapped in `Try { } Catch { }` blocks. +The code directly following the Try call is "protected", meaning that +if any Throws occur, program control is directly transferred to the +start of the Catch block. + + +A numerical exception ID is included with Throw, and is made accessible +from the Catch block. + + +Throws can occur from within function calls (nested as deeply as you +like) or directly from within the function itself. + + + +Limitations +----------- + + +This library was made to be as fast as possible, and provide basic +exception handling. It is not a full-blown exception library. Because +of this, there are a few limitations that should be observed in order +to successfully utilize this library: + +1. Do not directly "return" from within a `Try` block, nor `goto` + into or out of a `Try` block. + + *Why?* + + The `Try` macro allocates some local memory and alters a global + pointer. These are cleaned up at the top of the `Catch` macro. + Gotos and returns would bypass some of these steps, resulting in + memory leaks or unpredictable behavior. + + +2. If (a) you change local (stack) variables within your `Try` block, + AND (b) wish to make use of the updated values after an exception + is thrown, those variables should be made `volatile`. Note that this + is ONLY for locals and ONLY when you need access to them after a + `Throw`. + + *Why?* + + Compilers optimize. There is no way to guarantee that the actual + memory location was updated and not just a register unless the + variable is marked volatile. + + As an example, if we had the following code, the value `b` is + very likely at risk. It is assigned to the value `3` inside the + `Try` block, but the compiler may or may not have written that + variable to an actual memory location when the Throw happens. If + it did, the `printf` will have a `3` for the second value. If not, + it will still have a `0`. Changing `b` to `volatile` would + guarantee it is the correct value. + + ``` + void func(int *a) + { + // ... + int b = 0; + Try { + *a += 2; + b = *a; + Throw(MY_EX); + } Catch(e) { + // ... + } + printf("%d ?= %d", a, b); + } + void main() + { + int x = 1; + func(&x); + printf("%d", x); + } + ``` + + With most compilers, the `*a` and `x` values are NOT at risk. + We're dereferencing the pointer, which usually will force + memory interaction. Optimizing compilers DO optimize, though, + and it IS possible that even these values may have been cached + and not written to the final memory location. In those instances, + they would both report `1`. + + If you have a lot of situations like this and a strong optimizing + compiler, it is best to reduce the optimization level when using + CException. + +3. Memory which is `malloc`'d or `new`'d is not automatically released + when an error is thrown. This will sometimes be desirable, and + othertimes may not. It will be the responsibility of the `Catch` + block to perform this kind of cleanup. + + *Why?* + + There's just no easy way to track `malloc`'d memory, etc., without + replacing or wrapping malloc calls or something like that. This + is a light framework, so these options were not desirable. + + + +API +--- + +###Try + +`Try` is a macro which starts a protected block. It MUST be followed by +a pair of braces or a single protected line (similar to an 'if'), +enclosing the data that is to be protected. It **must** be followed by a +`Catch` block (don't worry, you'll get compiler errors to let you know if +you mess any of that up). + + +###Catch(e) + +`Catch` is a macro which ends the `Try` block and starts the error handling +block. The `Catch` block is called if and only if an exception was thrown +while within the `Try` block. This error was thrown by a `Throw` call +somewhere within `Try` (or within a function called within `Try`, or a function +called by a function called within `Try`, etc). + +The single parameter `e` is filled with the error code which was thrown. +This can be used for reporting, conditional cleanup, etc. (or you can just +ignore it if you really want... people ignore return codes all the time, +right?). `e` should be of type `EXCEPTION_T` + + +###Throw(e) + +This is the method of throwing an error. A `Throw` should only occur from within a +protected (`Try` ... `Catch`) block, though it may easily be nested many function +calls deep without an impact on performance or functionality. `Throw` takes +a single argument, which is an exception id which will be passed to `Catch` +as the reason for the error. + +If you wish to rethrow an error, this can be done by calling `Throw(e)` with +the error code you just caught. It **is** valid to throw from a catch block. + + +###ExitTry() + +On rare occasion, you might want to immediately exit your current `Try` block +but **not** treat this as an error. Don't run the `Catch`. Just start executing +from after the `Catch` as if nothing had happened... That's what `ExitTry` is +for. + + +CONFIGURATION +------------- + +CException is a mostly portable library. It has one universal +dependency, and some macros which are required if working in a +multi-tasking environment. + +1. The standard C library setjmp must be available. Since this is part + of the standard library, chances are good that you'll be fine. + +2. If working in a multitasking environment, methods for obtaining an + index into an array of frames and to get the overall number of + id's are required. If the OS supports a method to retrieve Task + ID's, and those Tasks are number 0, 1, 2... you are in an ideal + situation. Otherwise, a more creative mapping function may be + required. Note that this function is likely to be called twice + for each protected block and once during a throw. This is the + only overhead in the system. + + +Exception.h +----------- + +By convention, most projects include `Exception.h` which defines any +further requirements, then calls `CException.h` to do the gruntwork. All +of these are optional. You could directly include `CException.h` if +you wanted and just use the defaults provided. + +* `EXCEPTION_T` + * Set this to the type you want your exception id's to be. Defaults to 'unsigned int'. + +* `EXCEPTION_NONE` + * Set this to a number which will never be an exception id in your system. Defaults to `0x5a5a5a5a`. + +* `EXCEPTION_GET_ID` + * If in a multi-tasking environment, this should be + set to be a call to the function described in #2 above. + Defaults to just return `0` all the time (good for + single tasking environments) + +* `EXCEPTION_NUM_ID` + * If in a multi-tasking environment, this should be set + to the number of ID's required (usually the number of + tasks in the system). Defaults to `1` (for single + tasking environments). + +* `CEXCEPTION_NO_CATCH_HANDLER(id)` + * This macro can be optionally specified. + It allows you to specify code to be called when a Throw + is made outside of `Try` ... `Catch` protection. Consider + this the emergency fallback plan for when something has + gone terribly wrong. + + +You may also want to include any header files which will commonly be +needed by the rest of your application where it uses exception handling +here. For example, OS header files or exception codes would be useful. + + +Finally, there are some hook macros which you can implement to inject +your own target-specific code in particular places. It is a rare instance +where you will need these, but they are here if you need them: + + +* `CEXCEPTION_HOOK_START_TRY` + * called immediately before the Try block + +* `CEXCEPTION_HOOK_HAPPY_TRY` + * called immediately after the Try block if no exception was thrown + +* `CEXCEPTION_HOOK_AFTER_TRY` + * called immediately after the Try block OR before an exception is caught + +* `CEXCEPTION_HOOK_START_CATCH` + * called immediately before the catch + + + +TESTING +------- + + +If you want to validate that CException works with your tools or that +it works with your custom configuration, you may want to run the test +suite. + + +The test suite included makes use of the `Unity` Test Framework. It will +require a native C compiler. The example makefile uses MinGW's gcc. +Modify the makefile to include the proper paths to tools, then run `make` +to compile and run the test application. + +* `C_COMPILER` + * The C compiler to use to perform the tests + +* `C_LIBS` + * The path to the C libraries (including setjmp) + +* `UNITY_DIR` + * The path to the Unity framework (required to run tests) + (get it at [ThrowTheSwitch.org](http://throwtheswitch.org)) + + + +LICENSE +------- + +This software is licensed under the MIT License + +Copyright (c) 2007-2020 Mark VanderVoord + +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. diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/docs/ThrowTheSwitchCodingStandard.md b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/docs/ThrowTheSwitchCodingStandard.md new file mode 100644 index 000000000..a85adef3d --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/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)* diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/CException.c b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/CException.c new file mode 100644 index 000000000..fdff8f475 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/CException.c @@ -0,0 +1,46 @@ +#include "CException.h" + +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wmissing-field-initializers" +volatile CEXCEPTION_FRAME_T CExceptionFrames[CEXCEPTION_NUM_ID] = {{ 0 }}; +#pragma GCC diagnostic pop + +//------------------------------------------------------------------------------------------ +// Throw +//------------------------------------------------------------------------------------------ +void Throw(CEXCEPTION_T ExceptionID) +{ + unsigned int MY_ID = CEXCEPTION_GET_ID; + CExceptionFrames[MY_ID].Exception = ExceptionID; + if (CExceptionFrames[MY_ID].pFrame) + { + longjmp(*CExceptionFrames[MY_ID].pFrame, 1); + } + CEXCEPTION_NO_CATCH_HANDLER(ExceptionID); +} + +//------------------------------------------------------------------------------------------ +// Explanation of what it's all for: +//------------------------------------------------------------------------------------------ +/* +#define Try + { <- give us some local scope. most compilers are happy with this + jmp_buf *PrevFrame, NewFrame; <- prev frame points to the last try block's frame. new frame gets created on stack for this Try block + unsigned int MY_ID = CEXCEPTION_GET_ID; <- look up this task's id for use in frame array. always 0 if single-tasking + PrevFrame = CExceptionFrames[CEXCEPTION_GET_ID].pFrame; <- set pointer to point at old frame (which array is currently pointing at) + CExceptionFrames[MY_ID].pFrame = &NewFrame; <- set array to point at my new frame instead, now + CExceptionFrames[MY_ID].Exception = CEXCEPTION_NONE; <- initialize my exception id to be NONE + if (setjmp(NewFrame) == 0) { <- do setjmp. it returns 1 if longjump called, otherwise 0 + if (&PrevFrame) <- this is here to force proper scoping. it requires braces or a single line to be but after Try, otherwise won't compile. This is always true at this point. + +#define Catch(e) + else { } <- this also forces proper scoping. Without this they could stick their own 'else' in and it would get ugly + CExceptionFrames[MY_ID].Exception = CEXCEPTION_NONE; <- no errors happened, so just set the exception id to NONE (in case it was corrupted) + } + else <- an exception occurred + { e = CExceptionFrames[MY_ID].Exception; e=e;} <- assign the caught exception id to the variable passed in. + CExceptionFrames[MY_ID].pFrame = PrevFrame; <- make the pointer in the array point at the previous frame again, as if NewFrame never existed. + } <- finish off that local scope we created to have our own variables + if (CExceptionFrames[CEXCEPTION_GET_ID].Exception != CEXCEPTION_NONE) <- start the actual 'catch' processing if we have an exception id saved away + */ + diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/CException.h b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/CException.h new file mode 100644 index 000000000..78f2f940c --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/CException.h @@ -0,0 +1,115 @@ +#ifndef _CEXCEPTION_H +#define _CEXCEPTION_H + +#include <setjmp.h> + +#ifdef __cplusplus +extern "C" +{ +#endif + + +#define CEXCEPTION_VERSION_MAJOR 1 +#define CEXCEPTION_VERSION_MINOR 3 +#define CEXCEPTION_VERSION_BUILD 2 +#define CEXCEPTION_VERSION ((CEXCEPTION_VERSION_MAJOR << 16) | (CEXCEPTION_VERSION_MINOR << 8) | CEXCEPTION_VERSION_BUILD) + +//To Use CException, you have a number of options: +//1. Just include it and run with the defaults +//2. Define any of the following symbols at the command line to override them +//3. Include a header file before CException.h everywhere which defines any of these +//4. Create an Exception.h in your path, and just define EXCEPTION_USE_CONFIG_FILE first + +#ifdef CEXCEPTION_USE_CONFIG_FILE +#include "CExceptionConfig.h" +#endif + +//This is the value to assign when there isn't an exception +#ifndef CEXCEPTION_NONE +#define CEXCEPTION_NONE (0x5A5A5A5A) +#endif + +//This is number of exception stacks to keep track of (one per task) +#ifndef CEXCEPTION_NUM_ID +#define CEXCEPTION_NUM_ID (1) //there is only the one stack by default +#endif + +//This is the method of getting the current exception stack index (0 if only one stack) +#ifndef CEXCEPTION_GET_ID +#define CEXCEPTION_GET_ID (0) //use the first index always because there is only one anyway +#endif + +//The type to use to store the exception values. +#ifndef CEXCEPTION_T +#define CEXCEPTION_T unsigned int +#endif + +//This is an optional special handler for when there is no global Catch +#ifndef CEXCEPTION_NO_CATCH_HANDLER +#define CEXCEPTION_NO_CATCH_HANDLER(id) +#endif + +//These hooks allow you to inject custom code into places, particularly useful for saving and restoring additional state +#ifndef CEXCEPTION_HOOK_START_TRY +#define CEXCEPTION_HOOK_START_TRY +#endif +#ifndef CEXCEPTION_HOOK_HAPPY_TRY +#define CEXCEPTION_HOOK_HAPPY_TRY +#endif +#ifndef CEXCEPTION_HOOK_AFTER_TRY +#define CEXCEPTION_HOOK_AFTER_TRY +#endif +#ifndef CEXCEPTION_HOOK_START_CATCH +#define CEXCEPTION_HOOK_START_CATCH +#endif + +//exception frame structures +typedef struct { + jmp_buf* pFrame; + CEXCEPTION_T volatile Exception; +} CEXCEPTION_FRAME_T; + +//actual root frame storage (only one if single-tasking) +extern volatile CEXCEPTION_FRAME_T CExceptionFrames[]; + +//Try (see C file for explanation) +#define Try \ + { \ + jmp_buf *PrevFrame, NewFrame; \ + unsigned int MY_ID = CEXCEPTION_GET_ID; \ + PrevFrame = CExceptionFrames[MY_ID].pFrame; \ + CExceptionFrames[MY_ID].pFrame = (jmp_buf*)(&NewFrame); \ + CExceptionFrames[MY_ID].Exception = CEXCEPTION_NONE; \ + CEXCEPTION_HOOK_START_TRY; \ + if (setjmp(NewFrame) == 0) { \ + if (1) + +//Catch (see C file for explanation) +#define Catch(e) \ + else { } \ + CExceptionFrames[MY_ID].Exception = CEXCEPTION_NONE; \ + CEXCEPTION_HOOK_HAPPY_TRY; \ + } \ + else \ + { \ + e = CExceptionFrames[MY_ID].Exception; \ + (void)e; \ + CEXCEPTION_HOOK_START_CATCH; \ + } \ + CExceptionFrames[MY_ID].pFrame = PrevFrame; \ + CEXCEPTION_HOOK_AFTER_TRY; \ + } \ + if (CExceptionFrames[CEXCEPTION_GET_ID].Exception != CEXCEPTION_NONE) + +//Throw an Error +void Throw(CEXCEPTION_T ExceptionID); + +//Just exit the Try block and skip the Catch. +#define ExitTry() Throw(CEXCEPTION_NONE) + +#ifdef __cplusplus +} // extern "C" +#endif + + +#endif // _CEXCEPTION_H diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/meson.build b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/meson.build new file mode 100644 index 000000000..c9afe2048 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/lib/meson.build @@ -0,0 +1,11 @@ +# +# build script written by : Michael Brockus. +# github repo author: Mark VanderVoord. +# +# license: MIT +# +cexception_dir = include_directories('.') + +cexception_lib = static_library(meson.project_name(), + sources: ['CException.c'], + include_directories: cexception_dir) diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/meson.build b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/meson.build new file mode 100644 index 000000000..e44cb906d --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/meson.build @@ -0,0 +1,48 @@ +# +# build script written by : Michael Brockus. +# github repo author: Mark VanderVoord. +# +# license: MIT +# +project('CException', 'c', + license: 'MIT', + meson_version: '>=0.53.0', + default_options: ['layout=flat', 'warning_level=3', 'werror=true', 'c_std=c11'] +) +lang = 'c' +cc = meson.get_compiler(lang) + +# +# Meson: Add compiler flags +if cc.get_id() == 'clang' + add_project_arguments(cc.get_supported_arguments( + [ + '-Wexit-time-destructors', + '-Wglobal-constructors', + '-Wmissing-prototypes', + '-Wmissing-noreturn', + '-Wno-missing-braces', + '-Wold-style-cast', '-Wpointer-arith', '-Wweak-vtables', + '-Wcast-align', '-Wconversion', '-Wcast-qual', '-Wshadow' + ] + ), language: lang) +endif + +if cc.get_argument_syntax() == 'gcc' + add_project_arguments(cc.get_supported_arguments( + [ + '-Wformat', '-Waddress', '-Winit-self', '-Wno-multichar', + '-Wpointer-arith' , '-Wwrite-strings' , + '-Wno-parentheses' , '-Wno-type-limits' , + '-Wformat-security' , '-Wunreachable-code' , + '-Waggregate-return' , '-Wformat-nonliteral' , + '-Wmissing-declarations', '-Wmissing-include-dirs' , + '-Wno-unused-parameter' + ] + ), language: lang) +endif + +# +# Sub directory to project source code +subdir('lib') +cexception_dep = declare_dependency(link_with: cexception_lib, include_directories: cexception_dir) diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/project.yml b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/project.yml new file mode 100644 index 000000000..ab4a290af --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/project.yml @@ -0,0 +1,37 @@ +--- + +# This project file is for using Ceedling to run CException's self-tests. The +# only requirement for USING CException is in the lib folder. + +:project: + :use_exceptions: FALSE + :use_test_preprocessor: FALSE + :use_auxiliary_dependencies: FALSE + :build_root: build + :test_file_prefix: Test + :which_ceedling: gem + :ceedling_version: 0.29.1 + :default_tasks: + - clobber test:all + +:extension: + :executable: .out + +:paths: + :test: + - +:test/** + - -:test/support + :source: + - lib/** + :support: + - test/support + +:defines: + :test: + - TEST + - CEXCEPTION_USE_CONFIG_FILE + :test_preprocess: + - TEST + - CEXCEPTION_USE_CONFIG_FILE + +... diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/test/TestException.c b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/test/TestException.c new file mode 100644 index 000000000..e248cb0f2 --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/test/TestException.c @@ -0,0 +1,391 @@ +#include "unity.h" +#include "CException.h" + +volatile int TestingTheFallback; +volatile int TestingTheFallbackId; + +void setUp(void) +{ + CExceptionFrames[0].pFrame = NULL; + TestingTheFallback = 0; +} + +void tearDown(void) +{ +} + +void test_BasicTryDoesNothingIfNoThrow(void) +{ + int i = 0; + CEXCEPTION_T e = 0x5a; + + Try + { + i += 1; + } + Catch(e) + { + TEST_FAIL_MESSAGE("Should Not Enter Catch If Not Thrown"); + } + + //verify that e was untouched + TEST_ASSERT_EQUAL(0x5a, e); + + // verify that i was incremented once + TEST_ASSERT_EQUAL(1, i); +} + +void test_BasicThrowAndCatch(void) +{ + CEXCEPTION_T e; + + Try + { + Throw(0xBE); + TEST_FAIL_MESSAGE("Should Have Thrown An Error"); + } + Catch(e) + { + //verify that e has the right data + TEST_ASSERT_EQUAL(0xBE, e); + } + + //verify that e STILL has the right data + TEST_ASSERT_EQUAL(0xBE, e); +} + +void test_BasicThrowAndCatch_WithMiniSyntax(void) +{ + CEXCEPTION_T e; + + //Mini Throw and Catch + Try + Throw(0xEF); + Catch(e) + TEST_ASSERT_EQUAL(0xEF, e); + TEST_ASSERT_EQUAL(0xEF, e); + + //Mini Passthrough + Try + e = 0; + Catch(e) + TEST_FAIL_MESSAGE("I shouldn't be caught because there was no throw"); + + TEST_ASSERT_EQUAL(0, e); +} + +void test_VerifyVolatilesSurviveThrowAndCatch(void) +{ + volatile unsigned int VolVal = 0; + CEXCEPTION_T e; + + Try + { + VolVal = 2; + Throw(0xBF); + TEST_FAIL_MESSAGE("Should Have Thrown An Error"); + } + Catch(e) + { + VolVal += 2; + TEST_ASSERT_EQUAL(0xBF, e); + } + + TEST_ASSERT_EQUAL(4, VolVal); + TEST_ASSERT_EQUAL(0xBF, e); +} + +void HappyExceptionThrower(unsigned int ID) +{ + if (ID != 0) + { + Throw(ID); + } +} + +void test_ThrowFromASubFunctionAndCatchInRootFunc(void) +{ + volatile unsigned int ID = 0; + CEXCEPTION_T e; + + Try + { + + HappyExceptionThrower(0xBA); + TEST_FAIL_MESSAGE("Should Have Thrown An Exception"); + } + Catch(e) + { + ID = e; + } + + //verify that I can pass that value to something else + TEST_ASSERT_EQUAL(0xBA, e); + //verify that ID and e have the same value + TEST_ASSERT_EQUAL(ID, e); +} + +void HappyExceptionRethrower(unsigned int ID) +{ + CEXCEPTION_T e; + + Try + { + Throw(ID); + } + Catch(e) + { + switch (e) + { + case 0xBD: + Throw(0xBF); + break; + default: + break; + } + } +} + +void test_ThrowAndCatchFromASubFunctionAndRethrowToCatchInRootFunc(void) +{ + volatile unsigned int ID = 0; + CEXCEPTION_T e; + + Try + { + HappyExceptionRethrower(0xBD); + TEST_FAIL_MESSAGE("Should Have Rethrown Exception"); + } + Catch(e) + { + ID = 1; + } + + TEST_ASSERT_EQUAL(0xBF, e); + TEST_ASSERT_EQUAL(1, ID); +} + +void test_ThrowAndCatchFromASubFunctionAndNoRethrowToCatchInRootFunc(void) +{ + CEXCEPTION_T e = 3; + + Try + { + HappyExceptionRethrower(0xBF); + } + Catch(e) + { + TEST_FAIL_MESSAGE("Should Not Have Re-thrown Error (it should have already been caught)"); + } + + //verify that THIS e is still untouched, even though subfunction was touched + TEST_ASSERT_EQUAL(3, e); +} + +void test_ThrowAnErrorThenEnterATryBlockFromWithinCatch_VerifyThisDoesntCorruptExceptionId(void) +{ + CEXCEPTION_T e; + + Try + { + HappyExceptionThrower(0xBF); + TEST_FAIL_MESSAGE("Should Have Thrown Exception"); + } + Catch(e) + { + TEST_ASSERT_EQUAL(0xBF, e); + HappyExceptionRethrower(0x12); + TEST_ASSERT_EQUAL(0xBF, e); + } + TEST_ASSERT_EQUAL(0xBF, e); +} + +void test_ThrowAnErrorThenEnterATryBlockFromWithinCatch_VerifyThatEachExceptionIdIndependent(void) +{ + CEXCEPTION_T e1, e2; + + Try + { + HappyExceptionThrower(0xBF); + TEST_FAIL_MESSAGE("Should Have Thrown Exception"); + } + Catch(e1) + { + TEST_ASSERT_EQUAL(0xBF, e1); + Try + { + HappyExceptionThrower(0x12); + } + Catch(e2) + { + TEST_ASSERT_EQUAL(0x12, e2); + } + TEST_ASSERT_EQUAL(0x12, e2); + TEST_ASSERT_EQUAL(0xBF, e1); + } + TEST_ASSERT_EQUAL(0x12, e2); + TEST_ASSERT_EQUAL(0xBF, e1); +} + +void test_CanHaveMultipleTryBlocksInASingleFunction(void) +{ + CEXCEPTION_T e; + + Try + { + HappyExceptionThrower(0x01); + TEST_FAIL_MESSAGE("Should Have Thrown Exception"); + } + Catch(e) + { + TEST_ASSERT_EQUAL(0x01, e); + } + + Try + { + HappyExceptionThrower(0xF0); + TEST_FAIL_MESSAGE("Should Have Thrown Exception"); + } + Catch(e) + { + TEST_ASSERT_EQUAL(0xF0, e); + } +} + +void test_CanHaveNestedTryBlocksInASingleFunction_ThrowInside(void) +{ + int i = 0; + CEXCEPTION_T e; + + Try + { + Try + { + HappyExceptionThrower(0x01); + i = 1; + TEST_FAIL_MESSAGE("Should Have Rethrown Exception"); + } + Catch(e) + { + TEST_ASSERT_EQUAL(0x01, e); + } + } + Catch(e) + { + TEST_FAIL_MESSAGE("Should Have Been Caught By Inside Catch"); + } + + // verify that i is still zero + TEST_ASSERT_EQUAL(0, i); +} + +void test_CanHaveNestedTryBlocksInASingleFunction_ThrowOutside(void) +{ + int i = 0; + CEXCEPTION_T e; + + Try + { + Try + { + i = 2; + } + Catch(e) + { + TEST_FAIL_MESSAGE("Should Not Be Caught Here"); + } + HappyExceptionThrower(0x01); + TEST_FAIL_MESSAGE("Should Have Rethrown Exception"); + } + Catch(e) + { + TEST_ASSERT_EQUAL(0x01, e); + } + + // verify that i is 2 + TEST_ASSERT_EQUAL(2, i); +} + +void test_AThrowWithoutATryCatchWillUseDefaultHandlerIfSpecified(void) +{ + //Let the fallback handler know we're expecting it to get called this time, so don't fail + TestingTheFallback = 1; + + Throw(0xBE); + + //We know the fallback was run because it decrements the counter above + TEST_ASSERT_FALSE(TestingTheFallback); + TEST_ASSERT_EQUAL(0xBE, TestingTheFallbackId); +} + +void test_AThrowWithoutOutsideATryCatchWillUseDefaultHandlerEvenAfterTryCatch(void) +{ + CEXCEPTION_T e; + + Try + { + //It's not really important that we do anything here. + } + Catch(e) + { + //The entire purpose here is just to make sure things get set back to using the default handler when done + } + + //Let the fallback handler know we're expecting it to get called this time, so don't fail + TestingTheFallback = 1; + + Throw(0xBE); + + //We know the fallback was run because it decrements the counter above + TEST_ASSERT_FALSE(TestingTheFallback); + TEST_ASSERT_EQUAL(0xBE, TestingTheFallbackId); +} + +void test_AbilityToExitTryWithoutThrowingAnError(void) +{ + int i=0; + CEXCEPTION_T e; + + Try + { + ExitTry(); + i = 1; + TEST_FAIL_MESSAGE("Should Have Exited Try Before This"); + } + Catch(e) + { + i = 2; + TEST_FAIL_MESSAGE("Should Not Have Been Caught"); + } + + // verify that i is still zero + TEST_ASSERT_EQUAL(0, i); +} + +void test_AbilityToExitTryWillOnlyExitOneLevel(void) +{ + int i=0; + CEXCEPTION_T e; + CEXCEPTION_T e2; + + Try + { + Try + { + ExitTry(); + TEST_FAIL_MESSAGE("Should Have Exited Try Before This"); + } + Catch(e) + { + TEST_FAIL_MESSAGE("Should Not Have Been Caught By Inside"); + } + i = 1; + } + Catch(e2) + { + TEST_FAIL_MESSAGE("Should Not Have Been Caught By Outside"); + } + + // verify that we picked up and ran after first Try + TEST_ASSERT_EQUAL(1, i); +} diff --git a/FreeRTOS-Plus/Test/CMock/vendor/c_exception/test/support/CExceptionConfig.h b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/test/support/CExceptionConfig.h new file mode 100644 index 000000000..66cb87e7b --- /dev/null +++ b/FreeRTOS-Plus/Test/CMock/vendor/c_exception/test/support/CExceptionConfig.h @@ -0,0 +1,46 @@ +#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 |