Message-ID: <47378768.9010003@byu.net>
Date: Sun, 11 Nov 2007 15:51:20 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin 1.5.24-2 gcc 3.4.4 stdio.h
References: <E1Ir8WT-00060s-7N AT owl DOT gateway DOT 2wire DOT net>
In-Reply-To: <E1Ir8WT-00060s-7N@owl.gateway.2wire.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
> 
> typedef-name:
>   identifier

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
list.

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
<stdio.h>.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 AT byu DOT net
-----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

iD8DBQFHN4dn84KuGfSFAYARAs+qAJ9DZyE/XYMSdLmQ4jETQIpdMOrBLACg2KAj
KXaBXlb0cUBC/bP8VgVTePU=
=VDrt
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/