Closed avrs-admin closed 2 years ago
Thu 06 Jan 2005 08:29:29 AM CET
Look, please, the optimized strtol, patch #3618. Twice speed up, and 32 bytes stack usage decrease. Code size the same.
Eric Weddington
In the patch for this bug, can you rewrite your typecasts using the types found in stdint.h? (for example uint32_t, uint16_t)
That way it can start to be -mint8 compatible.
Thanks! Eric
Tue 11 Jan 2005 11:16:21 PM CET
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 12 Jan 2005 04:03:30 AM CET
Sorry, a mistake in last comment. Read as: But if anybody is needing a function, that must return value, "exactly 32 bits length"...
Joerg Wunsch
Your patch package has been incorporated, bolshoye spasibo!
Wed 05 Jan 2005 08:31:21 AM CET
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).
file #2324: strtol-20050105.diff
This issue was migrated from https://savannah.nongnu.org/bugs/?11494