This is the mail archive of the
mailing list for the GCC project.
Re: How is limits.h handled ?!?!?
- From: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 7 Jul 2003 20:39:42 +0100 (BST)
- Subject: Re: How is limits.h handled ?!?!?
- References: <20030707172527.GA2288@doctormoo>
On Mon, 7 Jul 2003, Nathanael Nerode wrote:
> The design seems to be barking mad. There's glimits.h, gsyslimits.h,
> limitx.h, limity.h, and fixincludes all mucking about together. And
> there's a couple of uses of '#include_next'.
> What's actually going on here? What's the idea?
<limits.h> is required of freestanding implementations, so GCC must
provide it. But the C standard specifies that it defines MB_LEN_MAX,
which is a library property, so that value may need to be got from the
system library. And POSIX also specifies some defines for <limits.h> (if
the relevant feature test macros are defined), so GCC's <limits.h> must
include the system library's version to get those defines.
(Those are the requirements for GCC's <limits.h> implementation. Someone
else will need to explain how the implementation design relates to the
requirements, as the only part of the design I'm responsible for is the
use of built-in macros to get the values relating to integer types in
<limits.h> correct in all cases.)
Joseph S. Myers