Issue with EXT when buffer ... grows?

[alexsnaps]

Looks like when I send a large chunk of msgpack data over, and the unpacker's buffer grows, some EXT's data get "corrupted" in a way.

I've setup a tiny example of the problem here: https://gist.github.com/alexsnaps/1296470ed59618d7a12db607aaddc3f2

Basically, simple.mp contains a MAP with 2 entries in it, where the keys are expected to be EXT 0x00. If the MSGPACK_CHUNK_SIZE is too small to hold the entire MAP, the first key input will not be found when looking for it, but there will be garbage there instead. Making the MSGPACK_CHUNK_SIZE big enough and avoid any internal buffer juggling, seems to solve the problem...

Am I to do something to have the unpacker deal with these EXT correctly? Am I doing this all wrong to begin with? Or is there a bug lurking there?

The code that's commented out and uses simple_no_ext.mp has STR keys in the MAP, that works fine out of the box afaict.

[redboltz]

@alexsnaps , thank you for reporting the issue. It seems that msgpack v2 API's buffer management bug.
I will fix it. Before I fix, you can use v1 API.
Please define the preprocessor macro MSGPACK_DEFAULT_API_VERSION=1.
See https://github.com/msgpack/msgpack-c/wiki/v2_0_cpp_versioning

[redboltz]

I fixed the issue by #562 .
Could you check it?

Here is an operation:

git checkout -b redboltz-fix_561 master
git pull https://github.com/redboltz/msgpack-c.git fix_561

[alexsnaps]

Works on my test case, y... Awesome thanks!