On Mon, 2012-12-24 at 17:11 -0800, Jonathan Nieder wrote: > Abou Al Montacir wrote: > > On Sat, 2012-12-22 at 10:21 -0800, Jonathan Nieder wrote: > > >> What happens if a stream ends at a buffer boundary, followed by > >> padding? Or if padding doesn't fit in the buffer, for that > >> matter? > [...] > > Please find attached new debdiff with fix of above mentioned issues. > > Getting closer. Does this correctly handle the case of a file with > zero streams? (It should error out.) How about a file with leading Let's see: We will read buffer, do no find zeros and go into decoder and then issue an error. > NUL bytes, which is also invalid? It will remove the zeros and then start decoding. I agree the file is invalid, but I don't think it could harm to decode any valid stream inside. > Does this implementation meet the following requirement (from the > spec)? > > | Stream Padding MUST contain only null bytes. To preserve the > | four-byte alignment of consecutive Streams, the size of Stream > | Padding MUST be a multiple of four bytes. Empty Stream Padding > | is allowed. If these requirements are not met, the decoder MUST > | indicate an error. Clearly it does not met this but could be done assuming few extra ifs. Hover, I assume we can save this extra code as soon as we don't loose data. My goal was more to avoid data loss for user rather than providing a specification conformant decoder. I just want to ensure that a user decoding a valid .xz file does not loose any data. If the decoder is more tolerant than the standard, my goal is met. Now if RT requires to have a full standard conformant decoder inside busybox, I can do it. > Thanks for your patient work. Thank you for your careful review. Cheers,
Attachment:
signature.asc
Description: This is a digitally signed message part