Re: RFC: *scanf vs. overflow

[Paul Eggert <eggert@cs.ucla.edu>]

On 5/23/20 9:11 AM, Rich Felker wrote:

> stopping on an initial prefix ... does not admit easily sharing a backend with strto*.

I don't see why. If the backend has a "stop scanning on integer overflow" flag
(which it would need to have anyway, to support the proposed behavior), then
*scanf can use the flag and strto* can not use it.

Anyway, this is not an issue for glibc, which has no such backend.

> that's contrary to the abstract behavior defined for scanf
> (matching fields syntactically then value conversion)

That's not really a problem. The abstract behavior already provides for matching
that is not purely syntactic. For example, string conversion specifiers can
impose length limits on the match, which means the matching does not rely purely
on the syntax of the input. It would be easy to say that integer conversion
specifiers can also impose limits related to integer overflow.

> It's also even *more
> likely* to break programs that don't expect the behavior than just
> storing a wrapped or clamped value

That's not true of the code that I looked at (see the URLs earlier in this
thread). That code was pretty carefully written and yet still vulnerable to the
integer-overflow issue.

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

Absolutely true right now. We are merely talking about (a) what sort of
implementation behavior is more useful for programs that are currently relying
on undefined behavior, and (b) what might be the cleanest addition to POSIX
later, to help improve this mess so that future programmers can use *scanf
safely in more situations.