Re: stdio.h: broken standard compliance.
On 2011-10-10 18:42Z, Kaz Kylheku wrote:
Corinna Vinschen writes:
$ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
^
fileno and pclose are *not* ANSI functions. Therefore, if you define
-ansi, you get the below errors. The newlib headers have explicit
#ifndef __STRICT_ANSI__ guards around the non-ANSI definitions.
[...]
I do not believe that your interpretation of the applicable standards
is
entirely correct.
The -ansi flag tells the GNU *compiler* to disable its built-in
extensions. So for instance the block evaluation syntax
({ expr1; ... ; exprn }) won't be available.
It does more than that:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/C-Dialect-Options.html
| The macro __STRICT_ANSI__ is predefined when the -ansi option is used.
| Some header files may notice this macro and refrain from declaring
| certain functions or defining certain macros that the ISO standard
| doesn't call for; this is to avoid interfering with any programs that
| might use these names for other things.
This is a strictly conforming program as defined by ISO standard C:
#include stdio.h
int fileno(int x) {return 3 * x;}
int main(){return fileno(2);}
With '-ansi', the posix declaration of fileno() is suppressed; if it
weren't, then that program would fail to compile. See:
http://gcc.gnu.org/ml/gcc-help/2004-09/msg00280.html
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
behavior, you might want to undef __STRICT_ANSI__ as appropriate.
--
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
Re: stdio.h: broken standard compliance.
Greetings, Kaz Kylheku! I see now from the archives that this list is configured to generate the unfortunate Reply-to header, which by many is considered a mailing list misconfiguration. First time I hear this bullshit. Mailing lists intended for public conversation. RFC 2822: ``When the Reply-To: field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent.'' [ 3.6.2 Originator fields ] Note that the Cygwin mailing list is not the author of this message; herefore, it is abusing the Reply-To: header in violation of the RFC which governs e-mail communication. It is author of message. If not, your message would have never reached the list. -- WBR, Andrey Repin (anrdae...@freemail.ru) 11.10.2011, 16:03 Sorry for my terrible english... -- 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
Re: stdio.h: broken standard compliance.
On Mon, Oct 10, 2011 at 09:58:50PM -0700, Kaz Kylheku wrote: Christopher Faylor writes: The convention in this mailing list is that you read the mailing list. I see now from the archives that this list is configured to generate the unfortunate Reply-to header, which by many is considered a mailing list misconfiguration. The cygwin mailing list does not set Reply-To. It does set Mail-Followup-To. [[ Apologies to Corinna: I understand now that you fell victim to this Reply-to trap! Argh! ]] I'm sure that Corinna actually knew just what she was doing. [rest of message snipped since it was based on an incorrect assumption] cgf -- 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
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 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
Re: stdio.h: broken standard compliance.
Christopher Faylor writes: The cygwin mailing list does not set Reply-To. It does set Mail-Followup-To. Effectively, there is no difference. This is an idiotic header that is defined by a 1998 IETF draft that was never approved, as far as I can find. This *DEAD* draft is here: http://tools.ietf.org/id/draft-ietf-drums-mail-followup-to-00.txt This document, in a nutshell, says Reply-To is broken, so here is a replacement. But the replacement is just as poor and not needed. Reply-To is not broken; it's a tool for a specific job. For a good discussion see: http://pjakma.wordpress.com/2009/07/08/mail-followup-to-considered-harmful/ (Highlight: ``Mail-Followup-To == more mess == even more brokenness.'') According to this cretinous IETF draft, the new header IS allowed to be set by mailing list expanders, unlike Reply-To, which is just for authors. Good grief, look: 2.3 Mailing List action A mailing list expander may insert the Mail-Followup-To header, with a reference to the list, if there is no previous Mail-Followup-To in the message. A mailing list expander SHOULD NOT change an existing Mail-Followup-To header, since this may reduce the set of recipients suggested in the original message. This is still a very rude and completely unnecessary thing for a mailing list expander to do. But it does seem to provide an API for communicating with the list by a nonsubscriber: set your own Mail-Followup-To header which the list must respect, if it obeys what the above document. This is even explicitly documented: 2.2 Sender Action [ ... ] 4. When a message is sent to a mailing list, which contains sublists, there is a risk that the sublists will insert Reply-To or Mail-Follow-Up-To headers referring to the sublist. If this happens, replies might be sent to the sublist, and thus not reaching the full set of readers of the primary mailing list. Use of the Mail-Followup-To can be used by the author or the primary mailing list to stop sublists inserting Mail-Followup-To in the header. Easier said than done for many people. Now you need every mail client to have the option to set the header, and for users to have the prescience of knowing when it has to be used. (Or sticking it into every outgoing message, just in case!) Kindly, someone please fix the Cygwin mailing list not to add this idiotic nonstandard header described in a 13 year old dead IETF draft. [rest of message snipped since it was based on an incorrect assumption] That isn't a fair characterization of everything that the rest of the message was about. -- 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
Re: stdio.h: broken standard compliance.
On Oct 9 11:23, Kaz Kylheku wrote:
On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku k...@kylheku.com
wrote:
reason, I cannot get a warning about fileno from this test case if
I add a reference to it. I will try to produce a minimal repro test
case for that.
In my real program I have -Wall, and I'm not taking the function
pointers.
With -Wall we get warnings about implicit declarations.
So, here is a better test case which shows that these identifiers are
not declared when they should be. Of course the two errors occur
without -Wall.
$ cat posix-ansi.c
#include stdio.h
void foo(void)
{
int (*f1)(FILE *) = fileno;
int (*f2)(FILE *) = pclose;
}
int main(void)
{
int x = fileno(stdin);
pclose(NULL);
return 0;
}
$ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
^
fileno and pclose are *not* ANSI functions. Therefore, if you define
-ansi, you get the below errors. The newlib headers have explicit
#ifndef __STRICT_ANSI__ guards around the non-ANSI definitions.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
Re: stdio.h: broken standard compliance.
Corinna Vinschen writes:
$ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
^
fileno and pclose are *not* ANSI functions. Therefore, if you define
-ansi, you get the below errors. The newlib headers have explicit
#ifndef __STRICT_ANSI__ guards around the non-ANSI definitions.
Hi Corinna,
(Could you use reply all? for discussions so the original
person is included, but the mailing list is kept in the loop with a
CC?
I had to dig your reply out of the online archives.)
I do not believe that your interpretation of the applicable standards
is
entirely correct.
The -ansi flag tells the GNU *compiler* to disable its built-in
extensions. So for instance the block evaluation syntax
({ expr1; ... ; exprn }) won't be available.
The -D_POSIX_C_SOURCE=2 tells the *library headers* to enable
their extensions to a certain revision of POSIX.
With -D_POSIX_SOURCE, programs must see pclose and fileno declared
in stdio.h
It is not correct for those headers to be testing GCC's
compliance level with __STRICT_ANSI__ to determine whether
to reveal these symbols.
FYI:
Summary of Feature Test Macros in the glibc documentation:
http://www.gnu.org/s/hello/manual/libc/Feature-Test-Macros.html
In your Linux manual pages:
$ man 7 feature_test_macros
In the Single Unix Specification:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02
Cheers ...
--
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
Re: stdio.h: broken standard compliance.
On Mon, Oct 10, 2011 at 11:42:45AM -0700, Kaz Kylheku wrote: Corinna Vinschen writes: $ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c ^ fileno and pclose are *not* ANSI functions. Therefore, if you define -ansi, you get the below errors. The newlib headers have explicit #ifndef __STRICT_ANSI__ guards around the non-ANSI definitions. (Could you use reply all? for discussions so the original person is included, but the mailing list is kept in the loop with a CC? I had to dig your reply out of the online archives.) The convention in this mailing list is that you read the mailing list. Practically speaking, if you want help, it pays to comply with convention rather than asking others to accommodate you. -- 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
Re: stdio.h: broken standard compliance.
Christopher Faylor writes: The convention in this mailing list is that you read the mailing list. Hi Christopher, I see now from the archives that this list is configured to generate the unfortunate Reply-to header, which by many is considered a mailing list misconfiguration. [[ Apologies to Corinna: I understand now that you fell victim to this Reply-to trap! Argh! ]] In other respects, this is a completely ordinary mailing list, like countless ones that came before it. How mailing lists work is that you use reply all to keep the discussion together. The mailing list is just another party that is on the CC list of the discussion, thereby keeping numerous other people (subscribers) in on the loop. The purpose of subscribing is to receive the e-mails; it is not a requirement for participating in the discussion. (Though many lists are member-only these days; but that is due to the spam problem.) Say, if I'm not reading the list, how come I can reply to you? It's because I'm making an effort to work around your misconfigured bouncer. I have your archives (thanks for putting them up). That's my preferred way of reading the list. Practically speaking, if you want help, it pays to comply with Where do you get the idea that I want help? Who do you think is helping whom here? People who find issues are the ones who help the developer. convention rather than asking others to accommodate you. I hope you realize that by accomodate you, you are actually referring to a proper use of the e-mail in the manner of how everyone does it everywhere on the planet. Namely that when you get an e-mail From: someone, that someone is among the recipients of the reply; and furthermore, that everyone else who was in the loop stays in the loop (if it is a discussion). It is your mailing list which munged the headers to make it difficult for you to reply to me, and that is what is creating the need for special accomodation. You can do whatever you want in your list, but do you not suppose it is in your interest to make it easy for people to communicate with you? If I have an issue report of some kind, please don't make me jump through hoops, and subscribe to have stuff dripping into my mailbox that I'm not interested in just so I can see the reply. Since you're letting non-subscribers post to the list, what are you protecting yourself from, anyway? Those evil bastard who are only interested in how their particular report turns out, but don't want to drink the whole jar of Cygwin Kool-Aid? Man, do you know how hard it is to get feedback from people? In this world, people just give up and move on, and you don't even know! You write some program, 50 people download it and install it, if you're lucky. Then unknown to you, 48 of them get stuck on something and you never hear from them. Anyway, you have the complete information to deal with (or not) the problem in the subject line. URL's given in my previous e-mail, etc. I do not need to be involved in any further discussion. Next time I have any kind of report, I will make it a complete kit in the very first e-mail, so I don't have to watch for clueless replies in the archives, and come back to burp you and change your dirty diapers after giving you the milk. Good luck. -- 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
Re: stdio.h: broken standard compliance.
One more thing: RFC 2822: ``When the Reply-To: field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent.'' [ 3.6.2 Originator fields ] Note that the Cygwin mailing list is not the author of this message; herefore, it is abusing the Reply-To: header in violation of the RFC which governs e-mail communication. -- 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
Re: stdio.h: broken standard compliance.
On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku k...@kylheku.com
wrote:
reason, I cannot get a warning about fileno from this test case if
I add a reference to it. I will try to produce a minimal repro test
case for that.
In my real program I have -Wall, and I'm not taking the function
pointers.
With -Wall we get warnings about implicit declarations.
So, here is a better test case which shows that these identifiers are
not declared when they should be. Of course the two errors occur
without -Wall.
$ cat posix-ansi.c
#include stdio.h
void foo(void)
{
int (*f1)(FILE *) = fileno;
int (*f2)(FILE *) = pclose;
}
int main(void)
{
int x = fileno(stdin);
pclose(NULL);
return 0;
}
$ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
posix-ansi.c: In function 'foo':
posix-ansi.c:5:23: error: 'fileno' undeclared (first use in this
function)
posix-ansi.c:5:23: note: each undeclared identifier is reported only
once for ea
ch function it appears in
posix-ansi.c:6:23: error: 'pclose' undeclared (first use in this
function)
posix-ansi.c:6:9: warning: unused variable 'f2'
posix-ansi.c:5:9: warning: unused variable 'f1'
posix-ansi.c: In function 'main':
posix-ansi.c:11:3: warning: implicit declaration of function 'fileno'
posix-ansi.c:12:3: warning: implicit declaration of function 'pclose'
posix-ansi.c:11:7: warning: unused variable 'x'
--
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
