Latest commit causes decode to break about go HOT 7 CLOSED

Thanks.

No need to send a minimal test case. I see the error. I'd upload a fix pronto.

from go.

Thanks!

from go.

Sorry, quick question, will the conversion of []byte to string potentially cause problems if the data is not UTF8 format?

from go.

The latest commit does fix our issue though. Thanks for the quick turn around!

from go.

Please re-test and confirm fix.

No - it will not cause an issue.

This is in line with the old logic before (see kMap method). We special-case and fast-tracked some common map types, and I forgot to replicate that check in there.

The reason for doing this, is that the original msgpack encodes a string as raw []byte (there was no separate string or binary type). When decoding, we need to make a determination what to do when we see raw bytes. We use the following to make that determination:

• If we see raw bytes as key in a map, then it must have been a string (because Go doesn't support slices as map keys). So we just convert it to a string (else you get the error you received that hashmap cannot have a slice as a key value because slices do not support equality).
• In any other situation that we see raw bytes in the stream, we use the value of the Option RawToString
  to determine what to do (either keep as []byte or convert to string).

A string in Go is just an immutable string of bytes - it doesn't specify an encoding. There are libs to treat it as utf8, utf16, runes (utf-32), etc.

from go.

And thanks for reporting this quickly. Much appreciated. I pride myself on not overlooking things, and am happy you caught this one for me quickly before others ran across it, and wasted time checking if the problem was on their end.

from go.

Thanks for the response and the excellent library! Cheers.

from go.