[FFmpeg-devel] [PATCH] ARMovie/RPL demuxer rev4
Sat Mar 29 02:31:29 CET 2008
On Sat, Mar 29, 2008 at 01:22:59AM +0000, M?ns Rullg?rd wrote:
> "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.
Which IMO is a really horrible idea, since that means the demuxer will
behave differently on 32 and 64 bit systems.
You could use one of the SCN?64 defines and uint64_t...
More information about the ffmpeg-devel