[FFmpeg-devel] [PATCH] ARMovie/RPL demuxer rev4

Måns Rullgård mans
Sat Mar 29 02:22:59 CET 2008


"Eli Friedman" <eli.friedman at gmail.com> writes:

> On Fri, Mar 28, 2008 at 6:06 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>> "Eli Friedman" <eli.friedman at gmail.com> writes:
>>
>>  > On Fri, Mar 28, 2008 at 4:38 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>  >> On Fri, Mar 28, 2008 at 04:13:02PM -0700, Eli Friedman wrote:
>>
>> >>  > +        if (offset >= 0xFFFFFFFFUL || video_size >= 0xFFFFFFFFUL ||
>>  >>  > +            audio_size >= 0xFFFFFFFFUL)
>>  >>  > +            error |= -1;
>>  >>
>>  >>  What exactly is this check good for?
>>  >
>>  > Overflow, so it doesn't silently accept 10000000000000 as an offset.
>>
>>  Quoting the C99 section on sscanf:
>>
>>   [...] if the result of the conversion cannot be represented in the
>>   object, the behavior is undefined.
>>
>>  This means that if the input contains a number too large for, in your
>>  case, a long, anything could be returned, including a seemingly
>>  sensible value.  Those checks are thus pointless.  If input validation
>>  at stage is a concern, don't use sscanf().
>
> Oh, hmm, okay.  I had assumed that all sscanf implementations would
> act like the glibc one and strtoul, which return 0xFFFFFFFF for
> out-of-range unsigned values.

You mean out-of-range unsigned 32-bit values.  You used the long type,
which is frequently 64 bits wide.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list