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.
Removed MSGPACK_API_VERSION_NAMESPACE(v1) from doxygen build.
It seems that Doxygen cannot parse a complicated macro such as MSGPACK_API_VERSION_NAMESPACE.
Added EXTRACT_ALL=YES to Doxyfle.
Added INPUT configuration variable that is point to include directory to Doxyfile.
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.
Updated all exceptions relate to unpack take a message parameter. It is better to explain the exceptional situation in detail. So far, just passing the exceptions name.
- Added new exceptions to explain limit over errors.
- Fixed ext maximum size problem.
Problem:
The type of m_trail was uint32_t but when parsing ext, it could be 0xffffffff + 1. +1 means type. See https://github.com/msgpack/msgpack/blob/master/spec.md#ext-format-family
Solution:
Modified the type of m_trail as std::size_t. If sizeof(std::size_t) == 4, 0xffffffff size of ext is an error. If sizeof(std::size_t) == 8, 0xffffffff size of ext is not an error. m_trail is 0xffffffff + 1.
Design cohice:
I chose std::size_t as the m_trail's type instead of uint64_t intentionally. On 64 addressing bit environment, there is no problem. On 32 bit environment, there is no problem except ext with maximum size. There is only one exception in the all msgpack format. Using uint64_t to support that, it's very expensive. On 32 addressing bit environment, allocating 0xffffffff + 1 bytes of memory couldn't succeed, so I believe that throwing an exception is a reasonable design choice in the case.
Added a referenced parameter to msgpack::unpack() and msgpack::unpacker::next().
msgpack::unpacked is a kind of handler that holds msgpack::object and msgpack::zone, so the size of msgpack::unpacked should be small. There is no reason to have referenced in msgpack::unpacked. msgpack user can get the same information using msgpack::unpack() and msgpack::unpacker::next().
Fixed referenced flag writing timing on next(). It should place before flush.
Added msgpack_tuple test for CMakeLists.txt
Untabified CMakeLists.txt
Added reference function test.
Removed zone::create and zone::destroy.
We can use zone as follows:
zone z; // on stack
zone* z = new zone; // on heap
Fixed a resource leak when zone::push_finalizer(msgpack::unique_ptr<T>) is called.
Removed obsolete unpack functions.
Updated examples that no longer use obsolete functions.
Added reference checking function to unpacked. ( unpacked::referenced() )
Added std:: namespace.
Added reference or copy choice function and default behavior:
When you use unpacker, default behavior is:
STR, BIN, EXT types are always held by reference.
When you don't use unpacker, default behavior is:
STR, BIN, EXT types are always held by copy.
The memory is allocated from zone.
You can customize the behavior passing your custom judging function to unpack() or unpacker's constructor.
Takatoshi Kondo