[Flac] Bug in bitreader for short reads?

Josh Coalson xflac at yahoo.com
Wed Jun 3 21:35:24 PDT 2009


you're right, this is fixed in CVS, see
http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478


--- On Sun, 5/31/09, Gilles Boccon-Gibod <bok at bok.net> wrote:

> From: Gilles Boccon-Gibod <bok at bok.net>
> Subject: [Flac] Bug in bitreader for short reads?
> To: flac at xiph.org
> Date: Sunday, May 31, 2009, 10:40 PM
> It seems that the bitstream
> reader is not working as it should (verified in version
> 1.2.0 and 1.2.1).The problem is as follows: if the data
> read by the read callback is not a multiple of 4, the bit
> reader will end up in a very bad state, where the
> bits_consumed field will grow without ever being reset to 0,
> and that causes everything to fail.This is not a
> case that's encountered very often, because in general
> (like for example when reading from a file), the read
> callback will return as many bytes as were asked for, which
> happens to be a multiple of 4. But when reading from a
> network socket, or some type of buffering code, it can
> happen that reads are shorter than requested, and not always
> multiples of 4, and that produces decoding
> problems.The problem is very easy to reproduce:
> in the read callback, always return 1 byte, regardless of
> how many bytes are asked for.For example, in a
> typical read callback routine, one can do the (simplified)
> following and see the problem:
> static
> FLAC__StreamDecoderReadStatus  FlacDecoder_ReadCallback(const
> FLAC__StreamDecoder* flac,              
>             FLAC__byte  
>              
> buffer[],              
>             size_t* 
>                
>   bytes,              
>             void*   
>                
>   client_data) {     *bytes=1;
>   /* <--- this was added to always return at most
> one byte */   
>  read_only_one_byte_into_buffer(buffer);
>     return
> FLAC__STREAM_DECODER_READ_STATUS_CONTINUE;
> } 
> 
> Any hints on how to get this fixed?
> 
> -- Gilles
> -----Inline Attachment Follows-----


      


More information about the Flac mailing list