This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: Prototypes [was Re: Patch for bugs 772 and 17913]


On Thu, 5 May 2005, Mark Mitchell wrote:
> >   <p>There are strict requirements for portability of code in GCC to
> > ! older systems whose compilers do not implement all of the ISO C standard.
> > ! GCC requires at least an ANSI C89 or ISO C90 host compiler, and code
> > ! should avoid pre-standard style function definitions, unnecessary
> > ! function prototypes and use of the now deprecated @code{PARAMS} macro.
>
> there seems to be a contradiction between the first and second
> sentences; do we require portability to old compilers or not?  I think
> at this point we require portability to non-standard libraries, but not
> non-standard compilers.


If you look closely you'll notice my modification to this first sentence:

Before:  ...whose compilers do not implement the ISO C standard.
After:  ...whose compilers do not implement all of the ISO C standard.


It's not that we require full and strict conformance to the entire
ANSI89 or ISO90 standards (including the runtime libraries, as you note),
just that the compiler must support enough of it to understand modern
function declarations.  I was thinking about they way we still have
BOOL_BITFIELD and ENUM_BITFIELD and friends and avoid known bugs in
popular host compilers.  In the sentence immediately after this change,
we refer to gcc/README.Portability that lists numerous portability issues
that wouldn't be an issue if we demanded perfect standards adherence.

It's a tricky business wording these clauses.  I think its important
that we try and allow GCC to be hosted from previous versions of GCC,
even if the bug might be preventing it is in violation of a standard.

I suspect that refering to a language standard (and all the baggage that
entails) isn't the best wording to use.  I'd prefer a more GNU autoconf
philosophy where GCC's ability to support a compilers is based on the
individual features that it provides/implements/supports.

Any suggestions for a better rewording?

Roger
--


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