This is the mail archive of the
mailing list for the Cygwin project.
Re: stdio.h: broken standard compliance.
- From: Kaz Kylheku <kaz at kylheku dot com>
- To: <cygwin at cygwin dot com>
- Date: Tue, 11 Oct 2011 13:45:41 -0700
- Subject: Re: stdio.h: broken standard compliance.
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
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
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
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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple