Avoid declaring the loop variable inside the for statement to keep
compatibility with c90:
unity.c:1408: error: for' loop initial declaration used outside C99 mode
Negating the most-negative signed integer results in overflow, which
is undefined behavior. Fix this by casting to an unsigned type first
(unsigned overflow is well-defined as it uses modular arithmetic).
Macros TEST_ASSERT_LESS_OR_EQUAL_HEX32_MESSAGE() and TEST_ASSERT_LESS_OR_EQUAL_HEX64_MESSAGE() need to be mapped to UNITY_TEST_ASSERT_SMALLER_OR_EQUAL_HEXnn() instead of UNITY_TEST_ASSERT_SMALLER_THAN_HEXnn()
Flush the unity stdout buffer before calling TEST_ABORT().
This is because if TEST_PROTECT() has not previously been called this will cause a segmentation fault and the stdout buffer will fail to print
Although the segmentation fault will still occur, the error that caused it will at least be displayed
MinGW supports a limited form of weak symbols, with the restriction
that weak/default implementations need to be defined in the same
translation unit they are called from. Strong/overriding symbols
may of course be specified in a different translation unit.
This is simpler and more flexible than embedding C code in the Ruby options
(:suite_setup and :suite_teardown). However, support for :suite_setup and
:suite_teardown is kept for backwards compatibility.
Several configurations are possible:
1. :suite_setup and :suite_teardown options provided and used.
2. :suite_setup and :suite_teardown options not provided (nil):
2a. Weak symbols not supported; suiteSetUp() and suiteTearDown() are not called.
It would be simpler to make user-provided functions mandatory in this case,
but it could break some pre-existing test suites.
2b. Weak symbols are supported and the stub implementations of suiteSetUp() and
suiteTearDown() are called if there are no user-provided functions.
2c. Weak symbols are supported but overridden by user-provided suiteSetUp() and
suiteTearDown() functions.
The existing implementation was not very good:
- It printed all very small values as "0.000000..."
- It did not distinguish positive and negative zero
- In some cases it printed extra garbage digits for single-precision values
(e.g. 3.9e+30 was printed as 3.90000013+30)
Tests have been updated to check that we now match printf("%.6g") for
1,000,000 randomly chosen values, except for rounding of the 6th digit.
The user can specify UNITY_OUTPUT_CHAR_HEADER_DECLARATION and
UNITY_OUTPUT_FLUSH_HEADER_DECLARATION when he would like to declare
UNITY_OUTPUT_CHAT or UNITY_OUTPUT_FLUSH respectivly
