Tue 11 Jan 2005 10:16:21 PM UTC, comment #3:
My opinion about "-mint8 compatibility":
Without -mint8 option, original (and patched) `strtol'
return `long' value, that is clipped in bounds LONG_MIN
and LONG_MAX. Such, strtol("5000000000",0,0) must return
2147483647.
With -mint8 option, `strtol' must also return `long'
value, clipped by LONG_MIN and LONG_MAX also. But, due
to reduced size of `long' (and reduced LONG_MAX, LONG_MIN),
the result of strtol("5000000000",0,0) must be 32767.
Such behavior agree, for example, glibc. On computer
with 64-bit long, result of strtol("5000000000",0,0) will
be 5000000000.
In such sence, strtol (original and patched) work true with
any size of `long'.
But if anybody is needing a function, that must return value,
"at least as 32 bits", it is necessity to write another function,
with another name, like:
int32_t strto32 (const char , char *, int) .
Thanks.
P.S. In patch #3618 (strtol optimization) second part of source
contain test for strtol with strings, like:
{ "2147483647", 0, 0x7fffffff, 0, 10 }
This test do not work with `-mint8' option and must be rewrited
with conditional compilation usage.
|
Wed 05 Jan 2005 07:31:21 AM UTC, original submission:
This is very old bug.
strtol() must return LONG_MIN for inputs too small.
Original Berkeley version do it. But avr-libc's version, for example, "-5000000000" --> -705032704 (simulavr, avr-gcc 3.3.4). You can reproduce such result on any 32-bit computer.
The reason is the attemption to negative LONG_MIN value (0x80000000).
Attached patch correct this mistake. (And it excude compiler warnings in comparison).
|