On 14/09/2018 02:30, Joel Sherrill wrote: > On Thu, Sep 13, 2018, 10:34 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> > wrote: > ----- Am 13. Sep 2018 um 14:07 schrieb joel j...@rtems.org > <mailto:j...@rtems.org>: > > > On Thu, Sep 13, 2018, 3:28 AM Sebastian Huber < > > sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > >> Hello, > >> > >> I test currently the tqm8xx BSP which worked fine until RTEMS 5. The > >> problem is that this BSP uses strtoul() to get some system > configuration > >> parameters from the boot loader. The Newlib used by RTEMS 5 has now > >> support for C locales in strtoul(). The C locale support needs an > >> executing thread with a valid Newlib reentrancy structure. This is > >> definitely not the case during bsp_start(). > >> > > > > Why do we now longer have a global reentrancy structure to fall back on? > > I think having a global reentrancy as a fall back just for the lowest > level > system start without an idle thread is a bit of overkill. > > The heavy weight C local support which was recently introduced in Newlib > is > not really the right thing for the embedded systems I know. There were > several complaints about this on the Newlib mailing list as well. The > root > cause for this is the C standard. So, basically the C standard strtoul() > is > unsuitable for embedded systems. The FreeBSD (sys/kern/strtoul.c) and > Linux > (lib/kstrtox.c) kernel have their own implementations. > > > FWIW the FACE Technical Standard does not include wide characters in ANY > profile > as of Edition 3.0. None of the RTOS vendors knew of any avionics users. It > wasn't viewed as a necessary feature. We could consider disabling it by > default. >
Is this something we could ot would want to control with newlib via a config option? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
