... and put it behind #ifndef CBOR_NO_FLOATING_POINT.
The functions were not really compiler support, but are internal
functionality of TinyCBOR. This commit also puts both the <math.H> and
<float.h> headers behind an #if, so constrained systems without floating
point support won't enable it.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The hosted version makes use of math functions (usually, we don't test
that CBOR_NO_FLOATING_POINT is defined).
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
On the Mac, the Clang compiler complains about our (required) use of
uint64_t, which is typedef'ed to long long. That type didn't exist in
C90.
On Windows, I forgot the CONFIG += console, resulting in
error LNK2019: unresolved external symbol _WinMain@16 referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
This fixes the issues in all the headers (even in the private headers),
but not all of them in the .c files. I only fixed those that didn't make
the code look much uglier or those for which GCC complains with
-std=c90. The compiler only warns about mixed mixed variable
declarations and code, unless you use -pedantic-errors.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Turns out that we were relying on undefined behaviour when doing
(uint64_t)fabs(val) == fabs(val)
This problem was noted when running our test data on an AArch64 build.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Adds ifdefs around the float handling to return an CborErrorUnknownType
if compiled without floating point support
Signed-off-by: Koen Zandberg <koen@bergzand.net>
Compilation for 8 bit architectures fails due to a bit shift larger than
8 for a uint8_t data type. This commit changes the data type to uint32_t
for the tag array.
Signed-off-by: Koen Zandberg <koen@bergzand.net>
So we can tell from the output if the library is increasing or not.
This also fixes a silly bug in testing non-tags, introduced by
0170ebdcdc.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Following Edward Welbourne's recommendation, first we remove the comments:
$ doxygen -s -u
Then we compare to the stock Doxyfile without comments (doxygen -s -g)
and save only what's to our file:
$ doxygen -s -g - | comm -13 Doxyfile > Doxyfile.new
$ mv Doxyfile.new Doxyfile
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Since we're not (yet) guaranteeing binary compatibility, let's use 0.5
as the "soversion".
This changes the version number stored in the VERSION file so that the
actual library file is "libtinycbor.so.0.5.0". As an indirect
consequence, the release will be tagged "v0.5.0", which sorts after
"v0.5-beta1".
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Freestanding C, as opposed to hosted C (see the macro), is restricted to
a few C headers and usually lacks a libc. In our case, that means we
cannot assume <stdio.h> and FILE* is present, but we do require
<string.h> (memcpy, memcmp).
This commit simply makes it easier for me to test that TinyCBOR still
compiles in freestanding mode. Eventually I need to test with an actual
Zephyr build (issue #40).
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
There was a section of code that was mostly the same, dealing with the
possibility of reading a Break (0xFF) as the next element in a map or
array. The only difference was that preparse_next_value() also
decremented the item count for the current list.
We could have used that, but that would have meant a +1 on the list,
which in turn lowers the number of possible elements from UINT32_MAX-1
to UINT32_MAX-2. Not a big deal, but we can avoid it by just splitting
to a new function and retaining tail-call optimisations.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The documentation said we encoded the negative value equivalent to the
passed absolute value. That means encode_number() requires the
subtraction.
This commit takes the opportunity to unit-test the rest of the integer
API in the parser.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
This gives us a little more room to add validation errors when we have
to keep binary compatibility.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of counting forward the number of items added, which meant we
couldn't know in cbot_encoder_close_container() whether we had added
enough, let's count backwards. The number is offset by 1 so we should be
at 1 if we added exactly as many items as we had expected to. Zero means
we added too many. Any other number means we added too few.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
GCC7 complains, though it's wrong:
src/cborvalidation.c:472:57: error: ‘previous’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
src/cborvalidation.c:485:61: error: ‘previous_end’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of always requiring FILE *. This does mean a slight code size
increase, since we now have to pass an extra parameter down the function
stack, plus we're making indirect calls, but it's worth it.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Some QCOMPARE did convert to int() so we would see an error number, but
not all comparisons did. For those those that didn't, QCOMPARE would
just print that the values differed, but not show what.
So try to harmonize on printing the error message.
I may not have caught all uses...
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Since Qt 5.9 has qfloat16, it became easier to write values. There was
no point with just the stand-in type, since the encoder would write
exactly the bytes we gave it.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Thiago Macieira