Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Sep 2007 16:44:35 +0200 (CEST)
From:      Harti Brandt <hartmut.brandt@dlr.de>
To:        Rhialto <rhialto@falu.nl>
Cc:        freebsd-standards@FreeBSD.org
Subject:   Re: standards/116346: FreeBSD has no conforming C implementation
Message-ID:  <20070914163307.F92964@knop-beagle.kn.op.dlr.de>
In-Reply-To: <200709141340.l8EDe6BN089882@freefall.freebsd.org>
References:  <200709141340.l8EDe6BN089882@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Sep 2007, Rhialto wrote:

R>The following reply was made to PR standards/116346; it has been noted by GNATS.
R>
R>From: Rhialto <rhialto@falu.nl>
R>To: Erik Trulsson <ertr1013@student.uu.se>
R>Cc: freebsd-gnats-submit@FreeBSD.org
R>Subject: Re: standards/116346: FreeBSD has no conforming C implementation
R>Date: Fri, 14 Sep 2007 15:35:06 +0200
R>
R> On Fri 14 Sep 2007 at 14:44:50 +0200, Erik Trulsson wrote:
R> > Yes, it does.  You do however have to invoke the C compiler in
R> > standard-conforming mode.
R> > By default gcc (like most C compilers) is not in standards-conforming mode.
R> > 
R> > Try invoking it as 'gcc -ansi' or 'c89' to get a C compiler conforming to
R> > the 1989 ANSI C standard.  (Invoking it as 'c99' or as 'gcc -std=c99' should
R> > get a C99 compiler, although I believe support for the 1999 C standard is
R> > not quite complete.)
R> 
R> Of course no makefile project ever does that at all, in practice, yet
R> they still expect to have the promised namespace available for their own
R> identifiers.
R> 
R> I was made aware of this problem when some project was using the "unix"
R> preprocessor definition as a feature test, and it failed to build on a
R> different BSD system, which IMHO is more correct in this regard.
R> 
R> I don't know where to look this up in POSIX and related standards, but I
R> don't expect that any of them actually *requires* a pre-#defined unix,
R> since they most likely don't want to contradict the C standard. If they
R> would mention any such feature test at all, they would require
R> #inclusion of some specific header first, or use a name which is
R> reserved to the implementation, such as __unix__.
R> 
R> Otherwise, by your reasoning, the default-invoked compiler could do
R> anything, and you would not need to bother having all those __-prefixed
R> names in /usr/include/sys/*.
R> 
R> Therefore, there is no standards-related reason for having "unix" and I
R> still argue for removing it.

If you look at posix you will see two things:

- Posix reserves a lot of names that are not in the implementation name 
space. As an example everything ending in _t or beginning with str is 
reserved. So unix might be reserved, but actually isn't.

- Posix defines the name of the C-compiler as c99. You invoked the 
compiler as gcc so it is no surprise that it does something different.

- As far as I remember C99 does not define the name of the compiler, so, 
if you're on a posix system you should use c99, if you are on a non-posix 
system it should be defined by the system so you cannot actually expect 
the name gcc to call the c99 compiler.

And yes, I understand you. I was several times hit by the Solaris 
compilers defining the identifier sun as 1. Argh.

harti



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070914163307.F92964>