cbor: decode undefined as null

[Stebalien]

See: ipfs/kubo#5776

This won't round-trip undef, it'll just convert it to null (which is what most decoders do anyways).

also fixes #53

[Stebalien]

CC: @vmx, @mikeal.

[vmx]

Sounds good to me. undefined signals an encoding error so I think interpreting it as null is fair (although I don't know the exact semantics of null in Go).

Encoding is kind of related. We should make sure that we normally don't ever end up with having undefined encoded in the first place. There's a consensus at dignifiedquire/borc#36 that the JS implementation of the encoder will error if it encodes a JavaScript undefined rather then using the CBOR undefined for it.

[Stebalien]

(although I don't know the exact semantics of null in Go).

We'll get a "zero" (empty) value.

[mikeal]

I didn't realize cbor had an undefined type.

I'm fine with de-serializing undefined from cbor to null. However, we should make sure that we never serialize undefined in any of our encoders, any undefined value should be interpreted as not actually existing (the key name should be unset), the only exception being if we need to encode a sparse array.

[Stebalien]

@mikeal take a look at the issue @vmx linked.

CBOR undefined != JavaScript undefined. In CBOR, undefined means "failed to encode" (our JS library was just misusing it). The alternative here is to just drop CBOR values with undefined fields.

[mikeal]

Interesting. I don't think we should drop them in decoders, but I do think the JS encoder should throw when it has a "failed to encode" state.

[Stebalien]

Got it. Should we just say that this is implementation defined behavior? That is, implementations may choose to decode undefined however they'd like (in go, we'll decode to "null").

[warpfork]

Should we just say that this is implementation defined behavior?

Yeah, I think for the specification of how dag-cbor relates to IPLD, calling this implementation defined is reasonable.

Although (and maybe this is obvious, but for clarity's sake) that also needs to come with a caveat that cbor which contains these 'undefined' values is not canonical.

[mikeal]

Should we just say that this is implementation defined behavior?

This sounds right. Languages diff enough that it's appropriate to allow each one to determine how to interpret and serialize to cbor's undefined.