Test that dagcbor and dagjson roundtrip cidlinks.
Including one interesting fix for dagjson. Since json can include whitespace -- and especially since our implementation currently uses prettyprinted json with quite a bit of said whitespace -- it's important to handle it consistently. We had a fun issue here: the json would be emitted with a trailing linebreak (as is generally what you want for printing to a terminal, etc!)... and thus hashed with it. Then, when loading the object, our parser will load exactly every byte needed to parse the object, then stop. Which... will cause it to return right before consuming that trailing linebreak. Which would cause that trailing linebreak to not be fed into the hasher, since we've carefully used a system which tees exactly the bytes consumed by the parser into the the hasher. So of course the link hash validation would fail. Woowee. I documented some of these details in an issue on the specs repo: https://github.com/ipld/specs/issues/108 There's not a super clear resolution over there as yet, but there seems to be a general agreement that whitespace should be tolerated, so... let's do so. As of this patch, the dagjson unmarshaller will consume all additional whitespace after finishing consumption of the json object iself. Dagcbor doesn't need a similar fix: there's no such thing as any possibility of other nonsemantic bytes, so there's nothing to absorb; and if we don't reach the end of the reader... we technically don't *care*: given the same reader over the same data being used to load the same link, we'll behave consistently; and therefore it follows that any additional bytes in the reader are unobservable to our universe. An earlier (and badly broken) draft of this attempted to put the read-to-end behavior in the cidlink package, but in addition to being unnecessary for dagcbor as described above, it also would've been simply *wrong*: the whitespace slurp is specific to dagjson. Signed-off-by: Eric Myhre <hash@exultant.us>
Showing
Please register or sign in to comment