[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