Bug in direct serialise/deserialise - possibly GHC bug?

[well-typed]

Bug in direct serialise/deserialise - possibly GHC bug?

[axman6]

For an none wondering, the url is https://gist.github.com/ondrap/a0791fafcce466966699 somehow all the '.'s were removed.

Definitely looks like a strange big to me - is a list of n+1 elements the canonical way to represent sum types? Been a while since i've read the docs. Also is there no need for something to close the list?

[ondrap]

It's one of the possible ways to do it - see https://github.com/well-typed/binary-serialise-cbor/blob/master/Data/Binary/Serialise/CBOR/Class.hs for the default instances. However what's fishy is that deserialise . serialise doesn't work, while deserialise . (force the list) . serialise works. I looked into the cbor sources and it seems to me that while quite dense with all those unsafe functions, it's still not as unsafe as to cause such behaviour.
BTW: it seems that the triggering point is serialising Integer with Text - what deserialised badly is the Integer. The Text value is probably causing the Integer to fall on some chunk boundary. My quickcheck tests didn't find any problem with other datatypes (might be harder to find).

[ondrap]

I have updated the gist with another test case - it seems there is still some error as it incorrectly parses forced ByteString if the bytestring consist of 1-byte chunks. This testcase shows an error in binary-serialise-cbor though.

• the deserialise . tokenize . serialise fails even when run in ghci; deserialise . serialise works correctly when run in ghci

[ondrap]

Ok, so both of this is either a GHC bug or some bug inside binary-serialize-cbor touching something it shouldn't touch. When loaded in GHCi, this produces different results when run repeatedly:

filter (\(a,b) -> not b) (map (\i -> (i,chunkProp [VNum (-41), VTerms [T.pack (replicate i 'a')]])) [0..800])

[ondrap]

I have fixed the problem, it seems to have no impact on performance. However, the accursedUnutterablePerformIO is available only in bytestring-0.10.6.0, the previous version had unsafeDupableIO. Does it make sense to build-depend on bytestring-0.10.6 and higher? I will try to add some test before doing a pull request.