This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: MIPS port and fixincludes
- To: Geoff Keating <geoffk at cygnus dot com>
- Subject: Re: MIPS port and fixincludes
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Tue, 18 Jan 2000 14:59:35 -0800
- Cc: egcs-patches at gcc dot gnu dot org
- References: <200001181634.QAA15775@phal.cygnus.co.uk> <38849E0B.A955E56F@sco.com> <14468.45021.579975.216916@cetus.cygnus.com> <20000118122137.A19994@wolery.cumb.org> <jmd7qz9gaq.fsf@envy.cygnus.com>
On Tue, Jan 18, 2000 at 02:16:29PM -0800, Geoff Keating wrote:
> Zack Weinberg <zack@wolery.cumb.org> writes:
> > I'm half tempted to say we should discard this fix entirely and say
> > that if your vendor provides broken headers, -ansi may not work, sorry.
>
> If you include "linux/a.out.h", using glibc, and you use -ansi, you
> should not be surprised if your program does not work, because
> "linux/a.out.h" is not an ANSI header. It's like trying to use
> fdopen() with -ansi: it will not work, because fdopen() will not be
> defined if you ask for C standard conformance.
>
> So this fix really only needs to be applied to the small number of
> standard C headers.
I think this may be too strict. It is reasonable to want a program
that's strictly conforming except that it uses read(2) / write(2) (and
therefore includes <unistd.h>) to compile cleanly with
-ansi -D_POSIX_SOURCE.
linux/a.out.h is outside the scope of any standard, of course...
zw