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: Subject: Re: stdio.h: broken standard compliance. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 11 Oct 2011 13:45:41 -0700 From: Kaz Kylheku 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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 "" 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