This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug stdio/15929] scanf doesn't set errno to ERANGE for unsigned short overflows


https://sourceware.org/bugzilla/show_bug.cgi?id=15929

benjaminmoody at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benjaminmoody at gmail dot com

--- Comment #5 from benjaminmoody at gmail dot com ---
POSIX doesn't specify anything.  Both POSIX and the C standard are
transparently idiotic on this point.  (What do they actually say?
They say that this is *undefined behavior*.  Not
implementation-defined.  Undefined, as in "pass the wrong string to
sscanf, and the library is permitted to set your printer on fire.")

Presumably somebody, somewhere, once wrote a broken implementation of
sscanf that would crash when given a value too large as input.  And it
was decided that permitting that implementation to be called
"conformant" was more important than having a sane standard.  That's
no justification for glibc not to behave sanely.

Note that glibc already goes beyond what the standards require, in
that it properly detects range errors for 'long', 'unsigned long',
'float', and 'double' values.  If all we cared about was following the
letter of the standards, the code could easily be simplified to use
'long long', 'unsigned long long', and 'long double' for everything.

(I suppose somebody might interject at this point and yell
"performance!", but seriously, you don't use sscanf for performance.
You use it because it's more convenient and easier to read than a
pagefull of strtol's.)

*Every* use of %d, %hd, %hhd, etc., is currently a bug, unless:

 - a maximum field width is used that makes overflows impossible, or

 - the input is so well constrained that you can guarantee ahead of
   time that it can never overflow (in which case, why are you using
   scanf?)

Isn't that enough of a reason to fix it?

As to documentation, the glibc manual is not "correct": it currently
makes no mention (that I can see) of how *scanf behaves on integer or
floating-point overflows.  If you refuse to fix this bug on the
grounds that programmers are expected to do their own range-checking,
then programmers need to know which conversions are safe to use in
that way (%ld good, %d bad.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]