[Ffmpeg-cvslog] r8498 - trunk/libavcodec/lzw.c
Baptiste Coudurier
baptiste.coudurier
Sun Mar 25 15:41:05 CEST 2007
Michael Niedermayer wrote:
> Hi
>
> On Sun, Mar 25, 2007 at 01:09:51PM +0200, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Sun, Mar 25, 2007 at 12:23:05AM +0100, bcoudurier wrote:
>>>> Author: bcoudurier
>>>> Date: Sun Mar 25 00:23:05 2007
>>>> New Revision: 8498
>>>>
>>>> Modified:
>>>> trunk/libavcodec/lzw.c
>>>>
>>>> Log:
>>>> break if eob is reached to avoid reading one too much byte
>>>>
>>>> Modified: trunk/libavcodec/lzw.c
>>>> ==============================================================================
>>>> --- trunk/libavcodec/lzw.c (original)
>>>> +++ trunk/libavcodec/lzw.c Sun Mar 25 00:23:05 2007
>>>> @@ -77,6 +77,7 @@ static int lzw_get_code(struct LZWState
>>>> s->bs = sizbuf;
>>>> if(!sizbuf) {
>>>> s->eob_reached = 1;
>>>> + break;
>>>> }
>>> * this check does not prevent reading over the end
>> at least it stops reading before the end.
>
> it does not, sizbuf is read from the stream and its value is at the
> mercy of whoever encoded the file
when sizbuf is good and 0, code must break.
> furthermore you broke the code, the return value is uninitalized after
> your change
c is initialized after the while (c = s->bbuf & s->curmask),
so return value IS initialized, what do you mean by uninitialized ?
>>> * this check only catches one eob case in the GIF branch of the if()
>>> * you are not maintainer of LZW
>> nobody is,
>
> true which means you should send a patch to ffmpeg-dev or if you dont _and_
> you break it then at least fix it and dont expect others to cleanup after you!
I did not break it, I ensured gif decoding was still working after that
change,
else I would not have commited it.
>> it works for me (tm),
>
> it worked before your change too
It was buggy, it must not read one byte too much.
>> and Im maintainer of gif,
>
> true
>
>
>> that case if
>> specific to gif, so Its like I am maintainer of that part of lzw, which
>> was in gifdec.c before.
>>
>>> * how do you know the code isnt intended to read a byte or 2 too much for
>>> simplicity and optimization reasons like almost all other code in lavc
>>> too?
>> Because buf_size is one less than what's actually read, and that's
>> problematic.
>
> ill remind you of the following in avcodec.h, just to prevent future
> missunderstandings
>
> /**
> * Required number of additionally allocated bytes at the end of the input bitstream for decoding.
> * this is mainly needed because some optimized bitstream readers read
> * 32 or 64 bit at once and could read over the end<br>
> * Note, if the first 23 bits of the additional bytes are not 0 then damaged
> * MPEG bitstreams could cause overread and segfault
> */
> #define FF_INPUT_BUFFER_PADDING_SIZE 8
that does not excuse the fact that lzw decoder reads one byte too much.
I want to check that last byte of gif is ';' and lzw decoder reads it,
while it should not so I can't check.
>>> considering these, please revert it
>> feel free to do IF you correct the code in a better way.
>
> the original code was correct, it was just not documented that the lzw
> code could read a little over the end
It was NOT correct, it read one byte too much.
> changing it so it does not read over the end is something which needs to
> be disscussed and of course if we decide to change its behaviour it should
> really not read over the end and not just check 1 out of several cases
> of reading over the end
It's not following gif specs ! I can't check gif EOF.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-cvslog
mailing list