[En-Nut-Discussion] But in launchpad toolchain and possibly others as well?
ole.reinhardt at embedded-it.de
Wed Nov 27 00:42:54 CET 2013
Am 26.11.2013 22:28, schrieb Ole Reinhardt:
> I just found a bug, that is very likely located in the launchpad arm
> toolchain or better said in newlib.
> If I try the following:
> #include <ctype.h>
> printf("Test: %c %c %c, %d %d %d\n",
> 'c', tolower('C'), toupper('c'),
> 'c', tolower('C'), toupper('c'));
> I get the following output:
> Test: c C c, 99 67 99
Things are getting even more strange. Also atoi and strtod fail. And
even worse, the result depends on the Nut/OS version used and the platform.
On Cortex M3 (LPC1768) everything works fine.
On Elektor Internet Radio I got the following results (which are always
All test were done on the EIR 1.0c
fprintf(uart, "Test atoi of \"10\": %d\n", atoi("10"));
fprintf(uart, "Test strtol of \"12\": %d\n", strtol("10", NULL, 10));
fprintf(uart, "Test tolower('C'): %c\n", tolower('C'));
fprintf(uart, "Test toupper('c'): %c\n", toupper('c'));
Test atoi of "10": -3
Test strtol of "12": -3
Test tolower('C'): C
Test toupper('c'): C
Test atoi of "10": 0
Test strtol of "12": 0
Test tolower('C'): C
Test toupper('c'): c
!!! See the different results of toupper('c') !!!
And for some input values atoi() seem to crash.
atoi("3") crashes on ethernut 4.10.3, while atoi("2") just returns an
invalid value (0).
but on Ethernut 5.2.1
atoi("2") crashes (which did not crash on 4.10.3) but atoi("1") again
survives, but returns a wrong value (0).
A crash means an abort exception.
I tested with different versions of the launchpad toolchain. At least
the lastest two versions and an unknown earlier version.
All versions showed the problem.
I'm feeling a little bit like a ghost hunter...
Has anybody else observed such a problem yet?
I really don't understand why different Nut/OS versions behave
different, as these routines are libc routines, and are not part of Nut/OS.
And I really don't have an idea what could cause these problems. And
what is the difference between AT91 and Cortex M3 here? Could this be
caused by any (different) compiler options? Or thumb vs. non-thumb?
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion