decode ints as float64

[jonasfj]

I get msgp: attempted to decode type "int" with method for "float64"

Server has an float64 and client is a node sending a number... I guess the node library encodes the number as an int to get the smallest possible wire format.

Clearly, int8, int16, int32 can all be decoded to a float64. I know this because js always uses double (float64) which is precise up-to 53bits. Hence, it can hold both int8, int16, and int32.

[jonasfj]

@imbstack, I guess JS clients have to rely on JSON format until this issue is resolved.

[philhofer]

Use msgp.Number as your field instead of an int. Then you can cast it
however you please.

On Wed, Apr 13, 2016 at 3:02 PM, Jonas Finnemann Jensen <
[email protected]> wrote:

@imbstack https://github.com/imbstack, I guess JS clients have to rely
on JSON format until this issue is resolved.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#152 (comment)

[philhofer]

(Or, rather, instead a float64.)

On Wed, Apr 13, 2016 at 3:07 PM, Philip Hofer [email protected] wrote:

Use msgp.Number as your field instead of an int. Then you can cast it
however you please.

On Wed, Apr 13, 2016 at 3:02 PM, Jonas Finnemann Jensen <
[email protected]> wrote:

@imbstack https://github.com/imbstack, I guess JS clients have to rely
on JSON format until this issue is resolved.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#152 (comment)

[jonasfj]

Hmm, that could work, but it adds a lot of complexity inside my application and prevents the same struct from working with ffjson...

Is casting int8,... to float64 really a problem.
I saw the other issue about this... Maybe I'll read that up too...

Thanks for the hint...

[jonasfj]

The snippet in #134 (comment)
Suggests to me that encoding a float64 as int8 is legal. Thus, by implication decoding an int8 to a float64 should be legal too.

I'm not suggesting that decoding an int64 to a float64 should be okay. At least not without some attribute where people clearly signal that they intend to do something risky.

Note: I think this is worth considering, as I get the impression that msgpack is intended as drop-in replacement for JSON. Which it won't be if the wire representation implies semantics.

[philhofer]

I believe he was referring to CBOR in that comment, not to msgpack.

But as for casting, see #143. I put the pull request out there a while ago and didn't see much interest.