[FFmpeg-devel] [PATCH] af_pan: Fix sscanf formats to work with buggy sscanf implementations

[Hendrik Leppkes]

On Sat, Sep 15, 2012 at 4:45 PM, Nicolas George <
nicolas.george at normalesup.org> wrote:

> Le nonidi 29 fructidor, an CCXX, Hendrik Leppkes a écrit :
> > If i understand the code correctly, the only place where white space
> really
> > matters is in the places where we manually go against the arg pointer,
> and
> > before those places is a skip_spaces now.
> > sscanf itself simply skips any leading spaces in the input, i confirmed
> > this on windows and linux.
>
> I could not be sure just reading at the patch, but as I said, if it was
> tested for various uses of spaces (and apparently it was), then please go
> ahead.
>
> > Leading spaces in the sscanf format string are completely unnecessary,
> its
> > implied by how sscanf works.
>
> Except for a few conversion specifiers, including %[foo].
>
> One last point though:
>
> skip_spaces() is precisely implemented using sscanf(*arg, " %n", &len): how
> comes it works while the other places do not?
>
>
>
The bug in the implementation doesn't trigger when %n is the first format
token.
It really only triggers when you reach EOF with a format token. On EOF, the
implementation checks if there is one trailing %n token, and if there is,
it fills its value. However, if there is a space before the %n, it fails
(instead of ignoring the space).
But if the %n is the first token to begin with, it works OK.

Buggy behaviour doesn't always have to make sense. :)