flat

flat copied to clipboard

Going through the flat specification and source code, it seems that word8,16,32,64,Natural are compatible between each other, up to their respective maxBounds of course.

By the word "compatible" I mean:

unflat @Word16 (flat @Word32 $ fromIntegral @Word16 maxBound)
Right 65535

and when crossing the respective maxBound:

> unflat @Word16 (flat @Word32 $ fromIntegral @Word16 maxBound + 1)
Left (BadEncoding (0x0000004208532c44,S {currPtr = 0x0000004208532c43, usedBits = 0}) "Unexpected extra byte in unsigned integer0")

This behaviour is what I expected and what is currently happening.

When considering the compatibility between Word64 and Natural:

>unflat @Word64 (flat @Natural $ fromIntegral @Word64 maxBound)
Right 18446744073709551615

this works as expected. However, when crossing the maxBound , this happens:

unflat @Word64 (flat @Natural $ fromIntegral @Word64 maxBound + 1)
Right 0

As you can see the decoded Word64 overflows. And it will continue overflowing (for some time) with a maxBound::Word64 periodicity. What I would expect is to return a Left (Bad Encoding ...) similar to the compatibility of Word16&Word32.

I don't know if this is the intended behaviour. What is even worse is that this Word64 decoder dWord64 will "eat up" 1 following byte from the serialized binary (perhaps even 2 bytes).

@tittoassini Any updates on this? Is this a bug or intended behaviour?

Just released on hackage version 0.5.2 that includes your fix.

Thanks again for your help.