Re: RFC: *scanf vs. overflow

[Rich Felker <dalias@libc.org>]

On Fri, May 22, 2020 at 08:06:34PM -0700, Paul Eggert wrote:
> On 5/22/20 6:16 PM, Rich Felker wrote:
> > A new feature
> > will not reliably be usable for decades in portable software, but new
> > documentation of existing universal practice would be immediately
> > usable.
> 
> We could do both.
> 
> Also, we could change glibc's behavior in a simpler way, by not adding a new
> flag; but if an integer is out of range, then scan only the initial prefix that
> fits, leaving the trailing digits for the rest of the format to scan. This also
> conforms to POSIX and is more likely to cause C programs to do the right thing
> (i.e., report a failure) than the current behavior does. And with luck perhaps
> we could eventually get POSIX to standardize this behavior.

I'm not really a fan of stopping on an initial prefix. While UB allows
anything, that's contrary to the abstract behavior defined for scanf
(matching fields syntactically then value conversion) and does not
admit easily sharing a backend with strto*. It's also even *more
likely* to break programs that don't expect the behavior than just
storing a wrapped or clamped value, since all the remaining fields
will misalign with the conversion specifier string.

FILE-based (as opposed to string-based) scanf forms inherently do not
admit any kind of "recovery" after mismatch without the caller seeking
backwards (requiring a seekable stream); many of them are lossy on
error. This is mainly a reaon not to use them, not a justification for
a weird definition for one special case.

I'm pretty sure the real answer here is just "don't use *scanf for
that."

Rich