[Bug libc/12667] fscanf silently converts signed to unsigned

["alexander.enchevich at yahoo dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12667

Alexander Enchevich <alexander.enchevich at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #5 from Alexander Enchevich <alexander.enchevich at yahoo dot com> 2011-04-12 16:13:12 UTC ---
I disagree with your decision to close this issue and insist that it is a bug.
Here's why (in ascending order of importance):

1. If you look at this page from the man-pages project:
http://www.kernel.org/doc/man-pages/online/pages/man3/fscanf.3.html , you will
see that the above info reads:
u      Matches  an unsigned decimal integer; the next pointer must be a
       pointer to unsigned int.

So there isn't any references to strtoul here. And there shouldn't be, as
strtoul is not related to the scanf family of functions and this would
introduce an unnecessary dependency on another totally unrelated party
(stroul).

2. Assuming you mean mathematical negation, the result in the above scan
operation is *not* negated.

It would have been negated if the fscanf took the -666666 and returned 666666,
but it doesn't. It simply stores the binary representation of -666666
(FFF5D3D6) into the provided pointer to unsigned int. As-is. Totally useless.
(not that negating it and storing +666666 would have been more useful..)

Looking into the strtoul manpages page the excerpt you mentioned reads:

     The  strtoul() function returns either the result of the conversion or, if
here was a leading minus sign, the negation of the result of the conversion...

Meaning (as I understand it):
  1. Convert provided string to number.
  2. If there was a leading minus sign then negate the number (that is multiply
it by -1.


3. I think you will agree with me that way more important than citing man-pages
and turning this into a "legal battle" is the context of how these functions
are used. 

And the context behind almost every ?scanf call is: we are processing some
input which we *hope* will mostly follow some predefined rules but we know
there *will be cases* when it doesn't. What do we do then? How do we detect the
erroneous conditions? With the current implementation, which happily gives us
back 4294300630 instead of providing some indication that a number beginning
with '-' is obviously not an unsigned number; there's nothing we can do to
process input correctly and safely with these functions. We are basically
forced to implement our own scanf's, reading files char by char, reading always
big signed int's and then filtering out the invalid numbers or some other
jumps-through-hoops along these lines

Please re-consider your decision to dismiss this bug report. Obviously there is
no way to predict what an input stream might produce and and these are
functions intended to process exactly these types of input streams. When we ask
for an unsigned integer and the stream produces a signed one there's got to be
a way to detect this condition. We can't have a function designed to process
live user input not being able to distinguish between -666666 and +4294300630
and giving back the same result for both cases...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.