In MSGPACK_CHECKED_CALL, the return value of snprintf is incorrectly
assumed to mean success if it is less than or equal to the buffer size.
The call should only be considered a success if the return value is less
than the buffer size.
This commit adds two unit tests that illustrates the issue and fixes the
issue, making the unit tests pass.
Fix possibly incorrect integer overflow check with an efficient correct check. Not fixing the issue where size == 0, unsure if this is by design, or what error to return if not.
Eliminated redundant zone allocation in unpacking process.
ARRAY and MAP is construced on the zone.
STR, BIN, and EXT refer to unpack buffer, and the buffer is reference
counted via zone (finalizer).
So zone is only needed if those types are appeared during unpacking
process.
I set zone to NULL by default. And the context has the pointer to
pointer to the zone. If the context meets ARRAY, MAP, STR, BIN, or EXT,
and zone (via pointer) is NULL, then allocate new zone.
It is lazy zone allocation strategy.
<<< Breaking change >>>
In the functions unpack() and parse(),
Old behavior: If any parse error is happend, offset is NOT updated.
New behavior: If any parse error is happend, offset is updated to the
position the error happened.
It helps MessagePack format error analysis.
If you want to old behavior, copy the original value of offset and then call unpack()
and/or parse().
This change make safe for `char = signed char`.
As the spec, argment of `isprintf()` must be representabe as an
`unsigned char` (or equal to EOF, not expected here).
Additionally, some implementation define it as a macro using array,
then it cause warning "array subscript has type `char` [-Wchar-subscripts]"
with `char` argments.
This patch makes unpacker_next_with_size(...), update p_bytes when
unpacker_next() returns MSGPACK_UNPACK_SUCCESS or MSGPACK_UNPACK_CONTINUE.
Signed-off-by: Eduardo Silva <eduardo@treasure-data.com>
This new function is an extension of the original msgpack_unpacker_next()
where it now adds third argument to store the number of parsed bytes for
the returned buffer upon a MSGPACK_UNPACK_SUCCESS case.
This is useful for cases where the caller needs to optimize memory usage
in the original buffer,s so upon success retrieval of the object, it can
later deprecate the already 'parsed' bytes.
For more details about the origins of this function please refer to the
following issue on github:
https://github.com/msgpack/msgpack-c/issues/514
Signed-off-by: Eduardo Silva <eduardo@treasure-data.com>
msgpack_object_print used fwrite to write binary data to a stream. The intention
of the function is to produce a human-readable representation of the object for
debugging purposes. Having arbitrary data dumped as is can cause issues with
terminals that interpret it as control sequences.
This change prints printable characters as is and unprintable characters as
hex-escapes ("\xNN"). Note that UTF-8 encoded characters will now be printed as
escaped sequence of UTF-8 bytes. This is an acceptable compromise, as doing
otherwise would require a light form of UTF-8 decoding and BIN-typed objects
should not be used to transport UTF-8 strings anyway (STR should be used
instead).
When you add or remove .h .hpp .c files in the msgpack-c library, run
make_file_list.sh. It generates (overwrites) Files.cmake for cmake and
src/files.mk for autotools. They are a part of repository managed
files. Files.cmake is included by CMakeLists.txt and src/files.mk is
included by src/Makefile.am.
libmsgpack.[a|so] is the library file for C++.
libmsgpackc.[a|so] is the library file for C.
Since version 1.0.0, the C++ parts of msgpack-c is a header only
library. So libmsgpack.* shouldn't be generated.
On the autotools building environment, removed libmsgpack.*
generation. On the cmake building environment, replaced libmsgpack.*
with libmsgpackc.* and set so-version to 2.0.0.
Torleiv Sundre