enum support had been incomplete.
This fix made enum support complete.
Replaced int with auto on c++11 scoped enum.
Replaced template specializations with function overloads on operator<< and operator>> for enum.
enum can convert to object with and without zone.
When you want to adapt enum, you need to write as follows:
// NOT msgpack.hpp
enum yourenum {
elem
};
MSGPACK_ADD_ENUM(yourenum);
// msgpack.hpp should be included after MSGPACK_ADD_ENUM(...)
int main() {
msgpack::object obj(yourenum::elem);
}
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.
- 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.
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.
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().
