X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE
X-Spam-Check-By:	sourceware.org
X-Cloudmark-SP-Filtered:	true
X-Cloudmark-SP-Result:	v=1.1 cv=KBSlDmMtPy+6dcT8s2HSk+nEQXlV1wil9/JK38/4IYQ= c=1 sm=1 a=W5crty74aesA:10 a=Bqtapk49eCgA:10 a=SV9grZ613K4A:10 a=BLceEmwcHowA:10 a=i7s4YuWtaOcA:10 a=IkcTkHD0fZMA:10 a=IaHBZPgZ0vV7m0nTkA8unw==:17 a=fQTsUWtNTY5D0f2rqJ8A:9 a=M2CHPyb9rLj6_61p6rsA:7 a=QEXdDO2ut3YA:10 a=9nvZqjWruDSZ3Et2:21 a=3Jvcrh5IVStbJCaP:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
To:	<cygwin AT cygwin DOT com>
Subject:	Re: stdio.h: broken standard compliance.
MIME-Version:	1.0
Date:	Tue, 11 Oct 2011 13:45:41 -0700
From:	Kaz Kylheku <kaz AT kylheku DOT com>
Message-ID:	<0c9ae3427a0adb3d84551896edb30f72@127.0.0.1>
X-Sender:	kaz AT kylheku DOT com
User-Agent:	Roundcube Webmail/0.4
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Greg Chicares writes:

>An argument could be made for giving _POSIX_C_SOURCE precedence over
> __STRICT_ANSI__ if both are defined; but as long as that's not the

The time to discuss this sort of stuff was back in 1990 or so,
when it was all settled and POSIX.1 came out. (Luckily, it went
your way, so you don't need a time machine.)

Even if you don't believe in the certainty of people's
interpretations of the standards, other implementations do it that 
way.

Since Cygwin is supposed to produce "that Linux feeling", this is
one way in which it doesn't.

The Linux "feeling" is that a program which uses "<stdio.h>"
and calls fileno compiles cleanly with -ansi -D_POSIX_SOURCE.

The Cygwin "feeling" is that you get ugly warnings, and perhaps
your program doesn't compile (takes the address of a function
which is not declared) or makes a bad call (implicit declaration
has the wrong prototype).

So if looks and feelings be substitutes for documents, it's still
wrong.

I suggest you people look into /usr/include/features.h on a glibc
system (and copy like crazy). Here is a nice comment from that file:

   The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__.
   If none of these are defined, the default is to have _SVID_SOURCE,
   _BSD_SOURCE, and _POSIX_SOURCE set to one and _POSIX_C_SOURCE set 
to
   200112L.  If more than one of these are defined, they accumulate.
   For example __STRICT_ANSI__, _POSIX_SOURCE and _POSIX_C_SOURCE
   together give you ISO C, 1003.1, and 1003.2, but nothing else.

I would say that the above summarizes the "Linux feeling"
on the matter, be it correct or not.

> behavior, you might want to undef __STRICT_ANSI__ as appropriate.

Again, I do not require help, or advice.
The above is just one of many possible workarounds.

It's not a real problem for me in this program anyway, because
the implicit declarations match the functions being called.

I can get my stuff working, and I don't have to be sending these 
reports.

Just send me an e-mail saying "Noncompliance is not a bug, do not
bother Cygwin with this petty crap" and you won't hear from me again
on this subject.

The project has the privilege of defining what is and isn't an issue.


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

- Raw text -