[Vorbis-dev] Re: vorbis-tools 1.2.0 Release Candidate

[ogg.k.ogg.k at googlemail.com]

> I'm not running a SPARC, but I am 64 bits here, let me know if
> you've got a test case you want to try.

If your 64 bit arch has sizeof(long)>sizeof(int), you can try any theora
stream, I think, from looking at the code (since it decodes a comment
packet). Run:

valgrind ogginfo foo.ogg

and we'll know.

Actually, we won't. It should work without the patch. I've looked at the
code:

static int _theora_unpack_comment(theora_comment *tc, oggpack_buffer *opb){
  int i;
  int len;

   _tp_readlsbint(opb,(long *) &len);

and I reckon it will work fine, even if there is a bug:

I'll assume the stack goes down. A pointer to a 64 bit len will thus be to
the lowest byte of len. Above this will be the other 3 bytes of len. Above
this will be the 4 bytes of i. Thus, the 64 bits pointed to by &len will be
composed of i and len. Thus, the call to _tp_readlsbint will fill 8 bytes,
so len and i will be filled. i probably will be filled with zero on LSB archs,
but not on MSB archs, where the actual interesting bits will go on i. I'm
not too sure what would happen after that, but it doesn't really matter.

Anyway, the interesting point is that I reckon even Valgrind wouldn't pick
up on that bad access, since len and i will be written to and are valid
memory slots, so it'll let it pass, but i will be written to by mistake. Which
doesn't even matter because it'll be initialized to zero in the loop that
follows.

But that's only trying to run the code in my head. So we need an arch
which is 64 bit, MSB, and with sizeof(long)>sizeof(int).

Unless my train of thought just derailed.