xlimits.h for embedded targets

[Joel Sherrill]

On Mon, 13 Oct 1997, Stephen Williams wrote:

> joel@OARcorp.com said:
> > The main problem for embedded targets is that there are headers files 
> > installed until after gcc is built because you need gcc to build the 
> > C library before you build the embedded OS itself.  Chicken and egg 
> > problem as much as anything else.
> 
> 
> 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.

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 is why
I refer to it as a chicken and egg problem.

> There are other standards, such as POSIX and XOPEN, that add things to
> the limits.h file, but they should be someone else's responsibility, not
> the compiler provider's.

Agreed.

> So, for a cross environment, GCC should provide a limits.h that has all
> the C specific parts. The OS may then extend the limits.h providing its
> own limits.h that only has POSIX/xopen/whatever specific stuff and using
> include_next to get the compiler specific stuff. I don't see how the compiler
> should care one wit what the POSIX parts of limits.h are.

Then maybe newlib should be "fixing" gcc's limits.h rather than the other
way around.  

> In uCR I have not trouble at all with limits.h. (Of course, I don't do the
> POSIX thing, either:-) Systems where gcc is the native compiler should have
> no trouble with it.

We had no trouble with limits.h until we got to POSIX support either. :)

> Could it be that the trouble you are having is with the C library you are
> using?

Could be.  I don't care how it is addressed.  I just don't see a clean
solution for a system in which the OS's limits.h is installed after
the compiler.  I don't remember any real general solutions being offered.

As an aside, I am not as concerned about this issue as it might seem based
on how many times I have griped about it on the egcs list.  Honestly rtems
gdb support is much more important to me. :)

--joel