Packed and unpacked types are not the same when using msgpack::type::variant.

[aint-no-programmer]

Problem appears when using msgpack::type::variant serialization for float number with zero decimal part.
Here motivation example:

# include <msgpack.hpp>
# include <cassert>

int main() {
	msgpack::type::variant val(212.f);
	std::stringstream ss;
	msgpack::pack(ss, val);

	auto unpacked = msgpack::unpack(ss.str().data(), ss.str().size());
	auto obj = unpacked.get();
	msgpack::type::variant restored_val;
	obj.convert(restored_val);

	assert(val == restored_val);//failed here
}

The reason for the failed assert is different types of variant’s values.
There are float type of val and uint64 type of the restored_val
I’ve found out that positive float number with zero decimal part is stored as uint64, hence when it is deserialized, it turns into an uint64 number.

As I know, it happens in line 1165 of msgpack/v1/pack.hpp, here:

template <typename Stream>
inline packer<Stream>& packer<Stream>::pack_double(double d)
{
    if(d == d) { // check for nan
        // compare d to limits to avoid undefined behaviour
        if(d >= 0 && d <= double(std::numeric_limits<uint64_t>::max()) && d == double(uint64_t(d))) {
            pack_imp_uint64(uint64_t(d));
            return *this;
        } else if(d < 0 && d >= double(std::numeric_limits<int64_t>::min()) && d == double(int64_t(d))) {
            pack_imp_int64(int64_t(d));
            return *this;
        }
    }
    //other code

Here https://gist.github.com/redboltz/672c5af16b2907488977 same problem.

Thank you for response.

msgpack version: 6.0.0
OS: Windows 10

[redboltz]

Thank you for reporting the issue. I think that it is caused by #1018 (#1017).
If after the decimal point is 0 then use INT format family.
This is allowed and expected behavir (See #1017 discusstion).

I will take a look msgpack::type::variant implementation and will try to fix msgpack::type::variant side.

[redboltz]

Fixed. Could you try #1071 ?

[aint-no-programmer]

Yes, i tried it works.
But now i have uint64 type stored in msgpack::type::variant, when i know i put the float type there.
Now it turns out that the type of the placed value does not match the type of the stored value.
Isn't that a problem?

And second, if i want to use user defined variant as in your example here i will face this problem again.

[redboltz]

Yes, i tried it works.
But now i have uint64 type stored in msgpack::type::variant, when i know i put the float type there.
Now it turns out that th

No, it is NOT a problem.

MessagePack format doesn't preserve progiramming language type information. That is by design.
msgpack::type::variant should be corresponding to MessagePack format, not the programming language type.
So msgpack::type::variant doesn't preserve the original type. That is by design. But you can extract as double from int64_t or uint64_t.

And second, if i want to use user defined variant as in [your example here]

I don't maintain old my gist. User can define type preserve version of custom adaptor if user wants to have it. In order to do that, the user need to pack not only values but also meta data (type information).

[aint-no-programmer]

I got it. Thank you for clarification.