Improving .deb

Posted May 28, 2019 22:19 UTC (Tue) by lmartelli (subscriber, #11755)
In reply to: Improving .deb by mbunkus
Parent article: Improving .deb

You probably meant : while (byte != 255)

Improving .deb

Posted May 29, 2019 6:58 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (3 responses)

No, I meant what I wrote. The size 1024 would be stored as 255, 255, 255, 255, 4. The size of 255 would be stored as 255, 0. See the examples in the documentation at https://www.xiph.org/ogg/doc/framing.html in the section "The encapsulation process".

Improving .deb

Posted May 29, 2019 12:57 UTC (Wed) by jezuch (subscriber, #52988) [Link] (2 responses)

Nope, still doesn't make sense :) The way you wrote it the loop would do at most two iterations, unless the bytes read were one 255 and a bunch of zeros. Which is not what the format specifies.

Did you mean: while (byte == 255); ?

(Oh the perils of commenting on a forum full of programmers ;) )

Improving .deb

Posted May 29, 2019 13:04 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (1 responses)

Well that was stupid… of course I meant "while (byte == 255)". Sorry :D

Improving .deb

Posted May 29, 2019 14:49 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

We really need support for comment unit tests here on lwn!

Improving .deb

Posted May 29, 2019 7:47 UTC (Wed) by weberm (guest, #131630) [Link]

Probably not. I was wondering about the condition as well. But consider how this supposedly encodes a size of 256: as one byte saying 255, and one saying 1. So the condition does make sense: Keep reading more single uint8_t's adding up to 255 bytes to the size while the read uint8_t contains its maximum value. (disclaimer: I don't know the container format, just extrapolating the grandparent comment).