Mail Archives: djgpp-workers/2004/02/27/13:03:41
> Date: Tue, 24 Feb 2004 16:44:50 -0600
> From: Eric Rudd <rudd AT cyberoptics DOT com>
>
> For me, the question whose answer is most unclear is about the proper
> thing to do when the string represents a number that is out of range.
> From a reading of 7.20.1.4, it appears to me that ULONG_MAX should be
> returned, regardless of whether the number was out of range in the
> positive or negative direction, and regardless of how far, but I'm by no
> means sure of that. Thus, the present strtoul() is correct for an input
> string of "-1", but it appears to treat other negative constants as if
> they were first converted to a signed long and then to an unsigned long,
> which I think is incorrect.
I'm not sure the current behavior is wrong. A case in point is a
line like below from a somewhat buggy C program:
unsigned foo = -5;
What do we expect a typical C compiler to produce? I think we expect
it to treat this as
unsigned foo = (unsigned)-5;
which produces what the current strtoul does. The reason this is
relevant is that a compiler (or any other similar processor) could
use strtoul to convert the string to an unsigned value.
Another case in point is
int bar = strtoul("-5", NULL, 0);
Don't we expect `bar' to be assigned the value -5?
So in my view, setting errno is okay, but the value should not
blindly be ULONG_MAX. I think ULONG_MAX is for the cases where we
try to convert a string whose numerical value cannot be reasonably
represented as a 32-bit number, like "11111111111111111111111111111"
or some such.
FWIW, the GNU/Linux documentation of strtoul explicitly says that
ULONG_MAX is returned and errno is set only if the original value
would overflow. Curiously, it also says:
The strtoul() function returns either the result of the
conversion or, if there was a leading minus sign, the
negation of the result of the conversion
Does this mean it will return 5 in the last example above? Can
someone try this on a GNU/Linux box?
- Raw text -