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.