On 2022-12-09 2:33 PM, Alejandro Colomar via Libc-alpha wrote:
Technically, the behavior is undefined if the result of the conversion
cannot be represented in the object being assigned to by scanf. (In
the case of glibc, that probably results in either the integer object
being set to a truncated version of the input integer, or the integer
object being set to a truncated version of LONG_MIN or LONG_MAX,
depending on the actual number.)
Hmm, UB. Under UB, anything can change, so error reporting is already
unreliable. If EOF+ERANGE can _only_ happen under UB, I'd rather remove
the paragraph. Please confirm.
BUGS
The `scanf` functions have undefined behavior if numeric input
overflows. This means it is *impossible* to detect malformed input
reliably using these functions.
Many input specifications (e.g. `%s`, `%[^\n]`) read a sequence of
characters into a destination buffer whose size is unspecified; any use
of such specifications renders `scanf` every bit as dangerous as `gets`.
Best practice is not to use any of these functions at all.
zw (no, this is not a joke)