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>
Probably a good idea anyway, plus solves a false positive warning:
src/compilersupport_p.h:192:34: error: ‘chunkLen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return __builtin_add_overflow(v1, v2, r);
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
src/cborparser.c:1163:16: note: ‘chunkLen’ was declared here
size_t chunkLen = chunkLen;
^~~~~~~~
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The C standard requires every the macro to be redefined every time that
<assert.h> is included. It does so you can change NDEBUG from one
But that also means a wrapper couldn't #define assert to their own
macro. So stop overriding.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The Windows builds on Appveyor use 5.9; the macOS builds on Travis use
the latest from Homebrew, which is currently 5.10.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The pretty-dumper code did not have a limit, assuming that the input had
been validated beforehand, so if the nesting was too deep, one would
have got an error before getting to the dumper.
However, it's not inconceivable that someone adds a logger code to a
packet a bit too early. So let's be defensive and apply the limiter here
too.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
- The defines(_BSD_SOURCE, _DEFAULT_SOURCE) were getting defined in multiple source files generating
warnings
- Solution is to conditionally define the above
- Enable BUILD_STATIC by default
- If BUILD_STATIC and BUILD_SHARED are both different from 1, return an
error
- If BUILD_STATIC is disabled, use shared library for binaries
- If both are enabled, use the static library
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Detect if this is an ELF system by checking if /bin/sh is ELF. This can
be configured manually with:
make BUILD_SHARED=0
or
make BUILD_SHARED=1
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Travis and Homebrew have been at odds: the Ruby in PATH is not what
Homebrew wants, so it prints:
/usr/local/Homebrew/Library/Homebrew/brew.rb:12:in `<main>': Homebrew must be run under Ruby 2.3! You're running 2.0.0. (RuntimeError)
Info in the Travis's own GitHub bug report indicates "brew update" fixes
this issue, even though it increases the build time.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
TinyCBOR release 0.4.2
This is a bugfix release. Important bugs fixed in this release:
- Fixed builds against a static cJSON
- Fixed MSVC builds
- Fixed builds on freestanding C implementation (no FILE* API)
- Fixed the return value of cbor_encoder_close_container when a previous OOM
condition had been detected
- Fixed the build in strict C89 mode (no C99 extensions)
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Observed issue on earlier version:
json2cbor.c:157:5: error: for loop initial declarations are only allowed in C99 mode
Note, it's not mandatory for current master branch
since build script already sets the c99 flag,
but it won't cause any harm.
Signed-off-by: Philippe Coval <philippe.coval@osg.samsung.com>
..\..\src\cborparser.c(149): warning C4013: '_byteswap_ushort' undefined; assuming extern returning int
..\..\src\cborparser.c(156): warning C4013: '_byteswap_ulong' undefined; assuming extern returning int
..\..\src\cborparser.c(163): warning C4013: '_byteswap_uint64' undefined; assuming extern returning int
This apparently also fixes the unit test failures.
FAIL! : tst_Parser::fixed(UINT32_MAX+1) Compared values are not the same
Actual (decoded) : "0_3"
Expected (expected): "4294967296"
.\tst_parser.cpp(233) : failure location
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Usually, if you ignore the OOM error, the encoder API may start
returning success, even though no buffer overrun happens. The way to
check if an OOM happened is with cbor_encoder_get_extra_bytes_needed,
which will return non-zero if a larger buffer is returned.
That said, the API was mostly already returning the OOM error
consistently, due to almost everything ending up calling
append_to_buffer(). This case was an exception.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
This is better than mucking with the struct's internals. I plan to
change it soon by adding more unions, to support fragmented buffers on
constrained OSes like Zephyr.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
We want CborErrorOutOfMemory to be the only negative value (or at least
with sign bit set), so the internal error constant can't be that.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Technically, they should be allowed on the BSDs, but it's far easier to
whitelist than blacklist.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Some people may want to use tinycbor as a shared library instead of
as a static library, so providing a set of .so accordingly.
Even with the static library, I'm having trouble incorporating it
into another shared library, so providing -fPIC option as well.
Signed-off-by: Bertrand Roussel <broussel@sierrawireless.com>
Recent GCC have begun complaining about it. The buildsystem should do
this, not a header.
compilersupport_p.h:175:11: warning: bad option '-ffunction-sections' to pragma 'optimize' [-Wpragmas]
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Thiago Macieira