[MPlayer-dev-eng] Patches for NUT

[Rich Felker]

On Sun, Feb 05, 2006 at 07:37:19PM +0200, Oded Shimon wrote:
> On Sat, Feb 04, 2006 at 02:52:42PM -0500, Rich Felker wrote:
> > On Sat, Feb 04, 2006 at 10:49:15AM +0200, Oded Shimon wrote:
> > > > > > > remove 2^n header restriction, 03-header-repeat.patch .
> > > > > 
> > > > > ok
> > > > 
> > > > IMO the wording is slightly confusing and makes it sound like the
> > > > headers must be repeated at EACH 2^n position.
> > > 
> > > well, it says SHOULD, not MUST, I haven't got any better ideas.. We can 
> > > polish it later.
> > 
> > The issue isn't SHOULD/MUST, it's that your wording implied that
> > headers should appear at _each_ 2^n position.
> 
> OK, using your phrasing:
> Each set of repeated headers not at the beginning or end of the file should 
> be stored at the earliest possible position after 2^n for some integer 
> power n
> Note: this allows an implementation reading the nut file to locate backup 
> headers in O(log filesize) time as opposed to O(filesize)
> 
> Can I commit?

OK with me.

> > You should still check and reject invalid pts, even if checksum is
> > valid. This indicates (most likely) an incorrectly authored file.
> 
> We (will) have nutlint for that... If checksum is valid, I might add an 
> assert to check pts is ok. :)

I hope you don't mean assert(). This will be disabled anyway in a
production version, and it's always totally inappropriate for a
library to call assert or anything else that could affect the state of
a calling program (terminating the process counts as affecting the
state I think! :)

> > > I also considered 16 bit checksum, as adler32 is kind of a waste on 10-20 
> > > bytes, but 16 bits is too weak. :/
> > 
> > How is using 32 bits to verify 80-160 bits overkill?
> 
> Because of adler's behavior... after testing, I found that about 8 bits are 
> almost always zero (15 byte message), so it's effectively a 27 bit checksum 
> taking up 32 bits... (max values are 12 bits 'a' and 15 bits 'b')
> 
> 24 bit adler is even weirder than adler16, so that's no good. Does anyone 
> have any other thoughts regarding this?

I see. Michael, can you help with this? I have no good knowledge about
effectiveness of checksums.

Rich