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

[Reimar Döffinger]

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...