Re: [Cbor] Question about CBOR padding

[Matt Vollrath <[e-mail]>]

Michael Richardson <[e-mail]>; wrote:
> Thiago Macieira  <[e-mail]>; wrote:
>     > CBOR has no need for  padding and it does not have any byte sequence that can
>     > fill in for padding.
> 
> True.
> 
> You could pad with a sized or  series of indefinite length array that ended
> with no items.  I think it's best  to just read the first "element", and
> ignore the rest though.

I agree with reading the first element and ignoring the rest.

My experience with JavaScript CBOR libraries has not been kind, though.  
Every library I've tested ('cbor', 'cbor-js', 'fast-cbor') fails when 
there are any trailing bytes, even when using a method that should only 
return the first element.  This behavior appears to be in line with the 
spec, which says that decoders can handle anomalous data basically 
however they like.

The spec suggests that any attempt at padding is unsupported in 3.2:

 > CBOR data is well-formed if it uses
 > the initial bytes, as well as the byte strings and/or data items that
 > are implied by their values, in the manner defined by CBOR, and no
 > extraneous data follows (Appendix C).

So it seems like if somebody has a good reason to stuff CBOR data into 
PNG pixels, they'll need to separately convey the number of bytes to 
chop off of the end or use a decoder implementation that specifically 
supports the case.  I can see how this makes the decoder implementation 
requirements leaner.

The Python 'cbor' library gets a gold star for not being broken when 
there are trailing bytes.

Thanks
mv