This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin 1.5.24-2 gcc 3.4.4 stdio.h
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com
- Date: Sun, 11 Nov 2007 15:51:20 -0700
- Subject: Re: cygwin 1.5.24-2 gcc 3.4.4 stdio.h
- References: <E1Ir8WT-00060s-7N@owl.gateway.2wire.net>
-----BEGIN PGP SIGNED MESSAGE-----
According to Robert Kiesling on 11/11/2007 1:50 AM:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> I just downloaded cygwin 1.5.24-2 (just a couple of hours ago) and
>> compiled the following program with "gcc -ansi fred.c"
>> (NOTE the "-ansi" keyword):
> I have only the C99 standard in front of me, but its syntax should
> be the same as ANSI, which is:
The OP question was not on what valid syntax was, but why the newlib
headers pollute the namespace with identifiers not specified by ANSI C99
(such as pid_t). Of course, pid_t is allowed to be defined by <stdio.h>
in a POSIX-conforming header, and in fact, the OP's code violates POSIX,
since POSIX reserves *_t identifiers for type names. POSIX also admits
that its definition of <stdio.h> has extensions beyond what C99 requires.
I have several responses to the OP:
1) the newlib headers pollute the namespace in strict ANSI mode (or in
other words, gcc -ansi _still has bugs_ in newlib) because no one has
submitted patches to the newlib project to clean them up. Patches are
welcome, but should be directed to the newlib list rather than the cygwin
2) why are you trying to use -ansi in the first place? A strict ANSI C99
compilation environment is very restrictive in what you can code:
theoritically, it implies portability to other strict ANSI C99 systems,
but in reality, how many strict C99 compliant environments are there,
really? I think you are better off with POSIX for portability than strict
C99, because there are more systems trying for POSIX compliance rather
than just C99, and because POSIX adds so many more portable interfaces
above and beyond C99 (at the expense of some namespace clashes, as your
example proves). But even then, be aware that there are very few strictly
compliant POSIX systems (cygwin certainly fails to be one of them).
3) just because strict C99 requires that you be allowed to compile code
that #defines pid_t prior to inclusion of <stdio.h>, what does it buy you?
It is more pragmatic to write code that is portable to a wide variety of
not-quite-standard compliant systems (of which, newlib is one - it is not
quite C99 compliant), than to expect every system to obey every standard.
Which means you are better off not #defining pid_t before including
Don't work too hard, make some time for fun as well!
Eric Blake email@example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html