worrisome behavior when upgrading refmt

[tobowers]

Just wanted to note something we ran into in our codebase. We recently upgraded our refmt because it has a lot of performance improvements. However, we use uint64s in our objects. When you call https://github.com/ipfs/go-ipld-cbor/blob/master/node.go#L95 (Decode) here, those uint64s get unmarshaled into overflowed int and then re-encoded back... so the bytes and CID are different.

I realize the comment says that might happen, but this isn't "canonical cbor" we're talking about... this is a change from a uint64 into an overflowed Int that then gets reencoded.

The version currently in this library works fine... just wanted to give a "heads up" when you're thinking about upgrading.

[hsanjuan]

Thanks for reporting @tobowers

@warpfork is there anything actionable here? Shall we add a test?

[warpfork]

I made a commit about this way back in Sep 2nd of last year, and thought I pushed a link to that into chats for early review... but I guess that didn't get anywhere.

I raised it as a proper PR now (admittedly, as I probably should have in the first place): polydawn/refmt#52

Tests would be great; PR's welcome. I think they may need to have architecture flags: unless I've misunderstood something about golang's numbers, int is in fact a 64-bit sized thing on 64-bit builds, which means the described overflow wouldn't actually be seen on 64-bit builds.