Re: stdio.h: broken standard compliance.

Re: stdio.h: broken standard compliance.

[Kaz Kylheku]

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.

[Kaz Kylheku]

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]

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.

[Andrey Repin]

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 (anrdaemon@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.

[Greg Chicares]

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.

[Kaz Kylheku]

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.

[Kaz Kylheku]

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.

[Christopher Faylor]

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.

[Kaz Kylheku]

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.

[Corinna Vinschen]

On Oct  9 11:23, Kaz Kylheku wrote:
> 
> On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku <kaz@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.

[Kaz Kylheku]

On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku <kaz@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