Fix static analyzer complaint about INT64_MIN for big floats and decimal fractions (#173)
This fixes potential static analyzer complaints about INT64_MIN when decoding big floats and decimal fraction tags. This is only for the value INT64_MIN (which is a special case for two's complement arithmetic).
Both gcc and clang compilers seem to handle INT64_MIN min correctly so it is likely there is no problem for most uses.
A test for this has been added.
The inline designator has been removed from some of the functions to let the compiler/optimizer figure out whether inline is better or not.
Lots of comments have been added to the big float and decimal fraction decoding.
* Improve code for INT64_MIN; better comments
* comment improvements
Co-authored-by: Laurence Lundblade <lgl@securitytheory.com>
diff --git a/test/qcbor_decode_tests.c b/test/qcbor_decode_tests.c
index 810bb7a..e913854 100644
--- a/test/qcbor_decode_tests.c
+++ b/test/qcbor_decode_tests.c
@@ -6132,6 +6132,18 @@
static const struct NumberConversion NumberConversions[] = {
#ifndef QCBOR_DISABLE_TAGS
{
+ "Big float: INT64_MIN * 2e-1 to test handling of INT64_MIN",
+ {(uint8_t[]){0xC5, 0x82, 0x20,
+ 0x3B, 0x7f, 0xff, 0xff, 0xff, 0xff, 0x0ff, 0xff, 0xff,
+ }, 15},
+ -4611686018427387904, /* INT64_MIN / 2 */
+ EXP_AND_MANTISSA_ERROR(QCBOR_SUCCESS),
+ 0,
+ EXP_AND_MANTISSA_ERROR(QCBOR_ERR_NUMBER_SIGN_CONVERSION),
+ -4.6116860184273879E+18,
+ FLOAT_ERR_CODE_NO_FLOAT_HW(EXP_AND_MANTISSA_ERROR(QCBOR_SUCCESS))
+ },
+ {
"too large to fit into int64_t",
{(uint8_t[]){0xc3, 0x48, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, 10},
0,