On a couple of occasions I have found that libmad (v0.15.0b) generates
segmentation errors because it doesn't really bother checking
whether the end of buffer has been reached.
That is a real worry, because one of the first thing one usually
does when writing robust code is ensure that wherever a pointer
is used it is never allowed to go beyond available data.
Look at function mad_layer_II() for example.
Here we have a "struct mad_stream" containing "buffer",
"bufend", and "ptr" pointers.
Then just a few lines later, about line 382, we have the following
code:
for (ch = 0; ch < nch; ++ch)
allocation[ch][sb] = mad_bit_read(&stream->ptr, nbal);
Unbelievably just the ptr is passed to mad_bit_read(). This means that
mad_bit_read() can, and sometimes does, increment the "ptr" beyond "bufend".
This is really lame code, if you'll excuse the pun.
Somebody should run some tests that pass randomly corrupted packets
to libmad and catch all of the segmentation faults that libmad
will generate.
One solution to above problem would be to created a bufend ptr in
struct mad_bitptr (ie. mad_bit_init() should be passed buffer and bufend).
Or just rationalize lots of the code by joining buffer/bufend into
a new struct and never using a anything but that struct everywhere.
MAD.