The build fails after the transition to Apple silicon and I don't know
why:
```
: && /usr/bin/clang -Oz -g -Werror -arch arm64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names tools/json2cbor/CMakeFiles/json2cbor.dir/json2cbor.c.o -o tools/json2cbor/json2cbor libtinycbor.a -lcjson -lm && :
ld: library 'cjson' not found
```
Homebrew says it installed and CMake says it found it.
```
-- Checking for module 'libcjson'
-- Found libcjson, version 1.7.19
```
I won't investigate.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of saying Linux (a.k.a. glibc) has it and Apple has funopen(),
use the fact that we've just detected them and inform the .c source
which one it was.
Fixes#306
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of performing a lossy conversion to double and printing that.
It's irrelevant whether the parser on the other side can store this
precision, only that it can parse this. That includes numbers outside
the range of int64_t, which CBOR does support.
We do this by simply removing code from cbortojson.c and instead just
relying on what cborpretty.c already has.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
We weren't dereferencing the variable, so this should have been safe.
However, it isn't clear in the C and C++ standards whether it
legitimately was safe. So let's just fix it.
```
simplereader.c:180:9: warning: pointer ‘buf’ may be used after ‘free’ [-Wuse-after-free]
simplereader.c:177:5: note: call to ‘free’ here
```
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 3cba6b1 ("Use _Float16 for half conversions if available") added
support for using half-width float support in the compiler to perform
encoding operations, using the FLT16_MANT_DIG macro to check for
support on the given target.
However, on x86 GCC only supports this when SSE2 is enabled[1]. Unlike
clang and the other architectures where support for this is conditional,
GCC *does* define those macros even without SSE2 support, causing a
build failure:
In file included from cborencoder_float.c:29:
cborinternal_p.h: In function ‘encode_half’:
cborinternal_p.h:56:5: error: invalid conversion to type ‘_Float16’ without option ‘-msse2’
56 | _Float16 f = (_Float16)x;
| ^~~~~~~~
cborinternal_p.h: In function ‘decode_half’:
cborinternal_p.h:65:5: error: invalid conversion from type ‘_Float16’ without option ‘-msse2’
65 | return (float)f;
|
Work around this by additionally checking for this specific condition.
[1] https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html
Signed-off-by: Florian Larysch <fl@n621.de>
I think GCC says `__has_cpp_attribute(fallthrough)` is true because C++
supports it (it means "has C++ attribute"), but that doesn't apply to
the C language. This causes a compilation error:
```
compilersupport_p.h:57:41: error: expected expression before '[' token
57 | # define CBOR_FALLTHROUGH [[fallthrough]]
| ^
cborparser.c:225:13: note: in expansion of macro 'CBOR_FALLTHROUGH'
225 | CBOR_FALLTHROUGH;
| ^~~~~~~~~~~~~~~~
```
Instead, we should use the C23 `__has_c_attribute` to detect the C
attribute.
Fixes#293.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The static builds with -Os or -Oz are there only so we get the library
size in the output. For testing, let's compile as a shared library and
properly in debug mode.
For Linux, we've had Valgrind. For macOS, this is now an ASan build.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
TinyCBOR has been at version 0.x for 10 years. This commit declares we
are now quite mature. I'm skipping version 1.0 through 6.0 and simply
calling the 0.7.0 to be 7.0.
Since this is binary compatible with the 0.6 version, I'm keeping the
SONAME of the shared library simply "libtinycbor.so.0" (note: previous
SONAME was "libtinycbor.so.0.6").
The Makefile build is not updated.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
As the comment says, to ensure we don't accidentally use something from
a new edition of the language than C99. In 2015 I think compilers still
defaulted to C99, but now in 2025, they default to C17.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
When value_to_pretty is called with recursionsLeft=0 and an Array or Map
type, container_to_pretty is called with recursionsLeft - 1 = -1. This
breaks the recursion limit check.
In practice, this can be triggered with a CBOR data containing 1023
Arrays, a Tag and many more Arrays:
$ python3 -c 'import sys;sys.stdout.buffer.write(b"\x9f" * 1023 + b"\xc0\x9f" + b"\x9f" * 100000 + b"\xff" * 101024)' | ./bin/cbordump
Segmentation fault (core dumped)
This segmentation fault is due to the stack growing too much, due to the
quantity of recursive calls.
Fix this by reporting a proper error when recursionsLeft <= 0, instead
of when recursionsLeft == 0. The same input now produces:
[_ [_ [_ ... [_ 0([
-: internal error: too many nested containers found in recursive function
_ <nesting too deep, recursion stopped>
Moreover, using fewer nested arrays works fine:
$ python3 -c 'import sys;sys.stdout.buffer.write(b"\x9f" * 1023 + b"\xc0\x9f" + b"\x9f" * 1024 + b"\xff" * 2048)' |./bin/cbordump
[_ [_ [_ ... [_ 0([_ <nesting too deep, recursion stopped>])] ... ]]]
Also modify the test when formatting CborTagType to ensure
value_to_pretty is never called with a negative recursionsLeft.
When printing CBOR data containing NaN, function convertToUint64 does an
undefined behavior. This can be reproduced using test cases from
tests/parser/data.cpp:
$ make CC='clang -fsanitize=undefined'
$ printf "\xfb\x7f\xf8\0\0\0\0\0\0" | ./bin/cbordump
src/cborpretty.c:171:17: runtime error: nan is outside the range of
representable values of type 'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/cborpretty.c:171:17 in
nan
$ printf "\xf9\x7e\x00" | ./bin/cbordump
src/cborpretty.c:171:17: runtime error: nan is outside the range of
representable values of type 'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/cborpretty.c:171:17 in
nan
Fix this by checking whether the value to convert is not NaN.
When function text_string_to_escaped successfully parses a string and
fails to parse the next value (cbor_value_finish_string_iteration
returns an error), it correctly propagates the error but the string is
never freed.
This can be reproduced with:
make CC='clang -g -fsanitize=address'
printf '\x82\x60\xff' | ./bin/cbordump -j
clang's Address Sanitizer reports:
=================================================================
==20317==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x560b654b9916 in __interceptor_realloc (/tinycbor/bin/cbordump+0xa4916) (BuildId: f9933666b5d987b21f68c2887de4aebe93bc2bef)
#1 0x560b654f5c18 in escape_text_string /tinycbor/src/cbortojson.c:331:15
#2 0x560b654f3e29 in text_string_to_escaped /tinycbor/src/cbortojson.c:377:19
#3 0x560b654f267d in value_to_json /tinycbor/src/cbortojson.c:674:19
#4 0x560b654f34c2 in array_to_json /tinycbor/src/cbortojson.c:545:25
#5 0x560b654f2085 in value_to_json /tinycbor/src/cbortojson.c:627:19
#6 0x560b654f1baf in cbor_value_to_json_advance /tinycbor/src/cbortojson.c:816:12
#7 0x560b654ea928 in dumpFile /tinycbor/tools/cbordump/cbordump.c:76:19
#8 0x560b654ead2b in main /tinycbor/tools/cbordump/cbordump.c:149:9
#9 0x7fa9d7629d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
SUMMARY: AddressSanitizer: 1 byte(s) leaked in 1 allocation(s).
Fix this by freeing the string when cbor_value_finish_string_iteration
fails.
Fixes: e072bc1d78 ("CBOR-to-JSON: do properly escape JSON strings")
Both the C and C++ standards say it is Undefined Behavior to convert a
floating point number to integer if the input is out of bounds of the
destination type.
And indeed this started failing in recent builds, with
val = 18446744073709551616 (2^64)
it has probably been producing ival = 18446744073709551615 for a while,
but the conversion back to floating point now rounded up and compared
equal to the input.
So let's just fix it.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
And make CBOR_PRIVATE_API fall back to it.
We also need to provide the file for the old Makefile build too.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
This method allows for writing raw data directly to the encoding buffer. This can be useful if you have something stored as CBOR encoded data.
Fixes#162.
Signed-off-by: Tofik Sonono <tofiksonono@msn.com>
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
We were returning from the function with the memory we had allocated and
freed, if the second iteration over the string produced a failure that
didn't happen on the first one. This can't happen with pure memory
buffers, but can happen with an external data source that fails to
produce the same contents twice.
I'm documenting that the values in all error conditions except for OOM
are undefined, so one mustn't attempt to use them, even to free. This
does not change behaviour of the library, just documents.
But this commit does make it clear the OOM condition will return a valid
`*buflen` and `next`, the latter of which is new behaviour with this
commit.
Fixes#258.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
There's a discussion in the C and C++ communities whether you're allowed
to use the values of pointers that have been deallocated, if you don't
dereference them. Some argue that it is Undefined Behaviour in spite of
the numeric value stored in the variable not having changed.
Instead of arguing, let's just make sure we don't use the pointers after
they have become dangling. We only needed the offset of how far we've
written into the buffer to restore the state and we have a function that
returns exactly that.
Seen while debugging #259.
Drive-by keep the `buffersize` global variable unchanged until after
`realloc()` has returned with success.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Thiago Macieira