Re: xlimits.h for embedded targets

[Stephen Williams <steve at icarus dot icarus dot com>]

> Seems to me, from a strictly theoretical point of view, that there are
> parts of the limits.h that are compiler issues. This file is in fact
> introduced by the C standard. This part of limits.h should be entirely
> up to the compiler.


joel@OARcorp.com said:
> This is true.  gcc recognizes this division and if there is a system 
> limits.h will do an "#include_next" to get the one for the OS.  it 
> wraps the OS one with the compiler one in a sense.  The problem with 
> RTEMS is that there is no OS limits.h installed when gcc looks for it.

This may be the problem. What in linits.h does gcc care about, other
then those values it provides?

This hack probably exists to allow gcc to be installed in places where the
O/S limits.h header file is off limits, i.e. supplied by another compiler.
We should be doing it THE OTHER WAY AROUND for cross targets: it is the
O/S limits.h that should include_next the gcc limits.h. n'est pas? You as
the RTEMS author have control over this. Make your limits.h include_next
the compiler's limits.h, and make sure that gcc does *not* find it:-)

joel@OARcorp.com said:
> Then maybe newlib should be "fixing" gcc's limits.h rather than the 
> other way around.   

Yes! I think so. Makes sense to me, no?

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."