The parameter 'offset' of unpack() function family, not unpacker family, updates only when the function successfully finished.
The parameter 'offset' used to update even if a caller passes insufficient bytes to the unpack() function family.
The names of float format family are changed.
old new
dec -> f64
MSGPACK_OBJECT_DOUBLE -> MSGPACK_OBJECT_FLOAT
msgpack::type::DOUBLE -> msgpack::type::FLOAT
Client codes could have compile errors when it use dec, MSGPACK_OBJECT_DOUBLE or msgpack::type::DOUBLE.
The best way to fix such errors, update client code. If it can't, set MSGPACK_USE_LEGACY_NAME_AS_FLOAT macro.
Then both old names and new names are available.
When the original PR was applied, the resource leak had been fixed, but a dual free problem had been happened.
When msgpack_unpacker_next returns MSGPACK_UNPACK_CONTINUE, msgpack_unpacked::zone is not replaced. Then mespack_zone_free is called twice with the same object. msgpack_unpacked_destroy frees msgpack::zone when it is not NULL and set it to NULL.
Also, fixed memory leak (msgpack_sbuffer) on the test code.
Set compile settiong on MSVC. ".c" files are compliled as C, not C++. (msgpack_vc8.vcproj, CMakeLists.txt)
Fixed msgpack root object initialization problem on MSVC. {} initialization is not supported on MSVC.
Projects that use -Wconversion don't compile due to errors in msgpack header
files. This commit fixes all the errors in msgpack-c for when -Wconversion is
enabled.
Now I can even compile msgpack-c itself with -Wconversion and all my projects:
CFLAGS=-Wconversion ./configure
make
The memcpy approach is a workaround for gcc's bug. The speed performance on gcc is the same between both approach. But on clang, the memcpy approach is 10% slower than an assignment approach. Hence I added the switching approach code using compiler checked macro.
Note: __GNUC__ is defined both gcc and clang. So I use __GNUC__ && !__clang__
