Re: _ELIX_LEVEL problems

[Jeff Johnston <jjohnstn at redhat dot com>]

When _ELIX_LEVEL is undefined (i.e. 0), there are no restrictions.  The 
_ELIX_LEVEL is not supposed to always be defined in newlib.h.  This 
allows the possibility of the maximum level (currently 4) to exclude 
functionality it does not wish to support and to allow future additional 
maximums.   Conceivably, yes, the level could be set to 0 and the tests 
could be made to reflect it, but it seems more intuitive that if no 
level is being set, there are no restrictions.  This vs "why does level 
0 have more functionality than level 3".

There is quite possibly some missing restrictions in the code as you 
have noted regarding vfscanf.c.

What specific problems are you seeing in your build that you alluded to 
in your other note?

-- Jeff J.

Joern RENNECKE wrote:
> What is supposed to happen when _ELIX_LEVEL is not defined?
> We used to build newlib as for maximum EL/IX level.  Now we
> only build files in EL/IX level 0, but these are build for maximum
> EL/IX level.
> Is _ELIX_LEVEL supposed to be always defined now?  But if so, there
> is no point of having lots of
> #if !defined (_ELIX_LEVEL) || _ELIX_LEVEL >= 2
> (and even some #ifndef _ELIX_LEVEL || _ELIX_LEVEL >= 2)
> in the sources.
> Moreover, vfscanf.c uses iswspace and other wide character functions
> without regard to the elix level.
> Obviously there need to be some guard there, but simply copying one
> of the existing ones won't help because of the above problem - since
> _ELIX_LEVEL is not defined for embedded platforms (at least not
> for sh-elf), the  offending code would still be included.