This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.
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: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]