This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: xlimits.h for embedded targets



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.

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.

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.

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.

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

-- 
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."




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]