This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: criteria.html open issues
- To: Joern Rennecke <amylaar at redhat dot com>
- Subject: Re: criteria.html open issues
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Fri, 15 Jun 2001 16:37:02 +0100 (BST)
- cc: Tim Hollebeek <tim at hollebeek dot com>, <gcc at gcc dot gnu dot org>
On Fri, 15 Jun 2001, Joern Rennecke wrote:
> > I've since realised that -traditional complicates this; if <limits.h>
> > relies on values such as __INT_MAX__ always being predefined by cc1, then
> > when compiling with -traditional it would be necessary to get the
> > predefined macros from cc1, remove __STDC ones, run tradcpp, then run cc1
> > again. Thus, I'd prefer tradcpp to be strictly a preprocessor for non-C
> > code, not something used for compiling C.
>
> You can use the specs to define __INT_MAX__ to a particular value when
> compiling with -traditional.
That would defeat the point of making the macros internal to cc1 - to
ensure that they are always accurate without needing ad hoc conditionals
either in specs or in limits.h.
Neil Booth's redesign of specs and option parsing may fix some problems
associated with predefined macros and compiler internal state getting out
of sync, but in general I don't see any good way to ensure that <limits.h>
is always accurate (and on some platforms it isn't) other than deriving it
directly from the compiler's own knowledge of type sizes.
No-one has said they need -traditional for anything apart from
preprocessing non-C code. I guess this means that -traditional does
indeed no longer serve much useful purpose, and I should (post-3.0)
produce a proper proposal for its removal (leaving only tradcpp for non-C)
for the SC to consider.
--
Joseph S. Myers
jsm28@cam.ac.uk