Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #9264 > unrolled thread

Random thought -- EOF and errno

Back to article view | Back to comp.lang.c

Contents

  Random thought -- EOF and errno Kenneth Brody <kenbrody@spamcop.net> - 2011-08-12 12:04 -0400
    Re: Random thought -- EOF and errno James Kuyper <jameskuyper@verizon.net> - 2011-08-12 12:27 -0400
      Re: Random thought -- EOF and errno Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 00:12 +0100
        Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-12 16:30 -0700
          Re: Random thought -- EOF and errno Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 01:27 +0100
            Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-12 18:28 -0700
              Re: Random thought -- EOF and errno Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 14:38 +0100
                Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-13 11:50 -0700
                  Re: Random thought -- EOF and errno Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-13 17:45 -0400
                    Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-13 18:04 -0700
                  Re: Random thought -- EOF and errno Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 22:53 +0100
                    Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-13 17:57 -0700
                      Re: Random thought -- EOF and errno Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-13 21:06 -0400
                        Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-13 18:39 -0700
                  Re: Random thought -- EOF and errno Tim Rentsch <txr@alumni.caltech.edu> - 2011-09-04 12:59 -0700
        Re: Random thought -- EOF and errno James Kuyper <jameskuyper@verizon.net> - 2011-08-12 20:51 -0400
          Re: Random thought -- EOF and errno Nobody <nobody@nowhere.com> - 2011-08-13 05:55 +0100
            Re: Random thought -- EOF and errno Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 14:49 +0100
          Re: Random thought -- EOF and errno Kenneth Brody <kenbrody@spamcop.net> - 2011-08-15 15:02 -0400
            Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-15 12:18 -0700
            Re: Random thought -- EOF and errno James Kuyper <jameskuyper@verizon.net> - 2011-08-15 21:54 -0400
              Re: Random thought -- EOF and errno Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-16 04:21 +0100
          Re: Random thought -- EOF and errno William Ahern <william@wilbur.25thandClement.com> - 2011-08-15 12:56 -0700
    Re: Random thought -- EOF and errno Seebs <usenet-nospam@seebs.net> - 2011-08-12 18:37 +0000
    Re: Random thought -- EOF and errno Nobody <nobody@nowhere.com> - 2011-08-13 06:00 +0100
      Re: Random thought -- EOF and errno Kenneth Brody <kenbrody@spamcop.net> - 2011-08-15 15:05 -0400
        Re: Random thought -- EOF and errno Keith Thompson <kst-u@mib.org> - 2011-08-15 12:14 -0700
        Re: Random thought -- EOF and errno gordonb.gl0ml@burditt.org (Gordon Burditt) - 2011-08-16 04:31 -0500

Page 1 of 2  [1] 2  Next page →

#9264 — Random thought -- EOF and errno

A stray thought wandered into my head this morning...

Given that 7.5p4 reserves macros that begin with E+digit or E+capital-letter 
for error codes, what allows the Standard to also define EOF in a manner 
unrelated to <errno.h>?  (Aside from "duh, it's the Standard, and it can do 
whatever it likes", that is.)

Just wondering.

-- 
Kenneth Brody

[toc] | [next] | [standalone]

#9268

On 08/12/2011 12:04 PM, Kenneth Brody wrote:
> A stray thought wandered into my head this morning...
> 
> Given that 7.5p4 reserves macros that begin with E+digit or E+capital-letter 
> for error codes, what allows the Standard to also define EOF in a manner 
> unrelated to <errno.h>?  (Aside from "duh, it's the Standard, and it can do 
> whatever it likes", that is.)

Those macros are reserved for use by the implementation; EOF is #defined
by the implementation; there's no conflict. In principle, EOF could even
be a valid errno value.

[toc] | [prev] | [next] | [standalone]

#9305

James Kuyper <jameskuyper@verizon.net> writes:

> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>> A stray thought wandered into my head this morning...
>> 
>> Given that 7.5p4 reserves macros that begin with E+digit or E+capital-letter 
>> for error codes, what allows the Standard to also define EOF in a manner 
>> unrelated to <errno.h>?  (Aside from "duh, it's the Standard, and it can do 
>> whatever it likes", that is.)
>
> Those macros are reserved for use by the implementation; EOF is #defined
> by the implementation; there's no conflict. In principle, EOF could even
> be a valid errno value.

I'm not sure it could be (or at least not in a useful way).  7.5p3 says
that errno "is set to a positive error number by several library
functions" but EOF must have a negative value (7.19.1p3).  It certainly
seems as if setting errno to EOF would not be confirming to the spirit
of the standard.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#9307

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>> A stray thought wandered into my head this morning...
>>> 
>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>> E+capital-letter for error codes, what allows the Standard to also
>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>> it's the Standard, and it can do whatever it likes", that is.)
>>
>> Those macros are reserved for use by the implementation; EOF is
>> #defined by the implementation; there's no conflict. In principle,
>> EOF could even be a valid errno value.
>
> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
> that errno "is set to a positive error number by several library
> functions" but EOF must have a negative value (7.19.1p3).  It certainly
> seems as if setting errno to EOF would not be confirming to the spirit
> of the standard.

If an implementation defined EOF with a positive value in <errno.h>, I
presume it would violate the standard, but what clause would it violate?

Such an implementation would fail to compile this:

#include <errno.h>
#include <stdio.h>
int main(void){}

which clearlyi would be A Bad Thing, but does the standard actually
require it to be accepted?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9308

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>>> A stray thought wandered into my head this morning...
>>>> 
>>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>>> E+capital-letter for error codes, what allows the Standard to also
>>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>>> it's the Standard, and it can do whatever it likes", that is.)
>>>
>>> Those macros are reserved for use by the implementation; EOF is
>>> #defined by the implementation; there's no conflict. In principle,
>>> EOF could even be a valid errno value.
>>
>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>> that errno "is set to a positive error number by several library
>> functions" but EOF must have a negative value (7.19.1p3).  It certainly
>> seems as if setting errno to EOF would not be confirming to the spirit
>> of the standard.
>
> If an implementation defined EOF with a positive value in <errno.h>, I
> presume it would violate the standard, but what clause would it violate?
>
> Such an implementation would fail to compile this:
>
> #include <errno.h>
> #include <stdio.h>
> int main(void){}
>
> which clearlyi would be A Bad Thing, but does the standard actually
> require it to be accepted?

What's your line of reasoning here?  I don't see why such an
implementation could not compile the above but I also don't see how you
could be in doubt that the above should be accepted.

(I have guesses about both of these but it seems wiser just to ask for
more detail.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#9317

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>>>> A stray thought wandered into my head this morning...
>>>>> 
>>>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>>>> E+capital-letter for error codes, what allows the Standard to also
>>>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>>>> it's the Standard, and it can do whatever it likes", that is.)
>>>>
>>>> Those macros are reserved for use by the implementation; EOF is
>>>> #defined by the implementation; there's no conflict. In principle,
>>>> EOF could even be a valid errno value.
>>>
>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>> that errno "is set to a positive error number by several library
>>> functions" but EOF must have a negative value (7.19.1p3).  It certainly
>>> seems as if setting errno to EOF would not be confirming to the spirit
>>> of the standard.
>>
>> If an implementation defined EOF with a positive value in <errno.h>, I
>> presume it would violate the standard, but what clause would it violate?
>>
>> Such an implementation would fail to compile this:
>>
>> #include <errno.h>
>> #include <stdio.h>
>> int main(void){}
>>
>> which clearly would be A Bad Thing, but does the standard actually
>> require it to be accepted?
>
> What's your line of reasoning here?  I don't see why such an
> implementation could not compile the above but I also don't see how you
> could be in doubt that the above should be accepted.
>
> (I have guesses about both of these but it seems wiser just to ask for
> more detail.)

Hypothetically,
<errno.h> has:
    #define EOF 42 /* Error on Ocelot Farm */
and <stdio.h> has:
    #define EOF (-1)

Then the preprocessed expansion of the above source file has:
    ...
    #define EOF 42
    ...
    #define EOF (-1)
    ...
which violates C99 6.10.3p2.

It's "obvious" that a program that has #include directives for any
combination of standard headers and is otherwise legal is still legal
(handwave meaning of "legal").  The question is, what clause of the
standard does this implementation violate by rejecting the program?
(I have no doubt that it violates the *intent* of the standard.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9344

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>>>>> A stray thought wandered into my head this morning...
>>>>>> 
>>>>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>>>>> E+capital-letter for error codes, what allows the Standard to also
>>>>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>>>>> it's the Standard, and it can do whatever it likes", that is.)
>>>>>
>>>>> Those macros are reserved for use by the implementation; EOF is
>>>>> #defined by the implementation; there's no conflict. In principle,
>>>>> EOF could even be a valid errno value.
>>>>
>>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>>> that errno "is set to a positive error number by several library
>>>> functions" but EOF must have a negative value (7.19.1p3).  It certainly
>>>> seems as if setting errno to EOF would not be confirming to the spirit
>>>> of the standard.
>>>
>>> If an implementation defined EOF with a positive value in <errno.h>, I
>>> presume it would violate the standard, but what clause would it violate?
>>>
>>> Such an implementation would fail to compile this:
>>>
>>> #include <errno.h>
>>> #include <stdio.h>
>>> int main(void){}
>>>
>>> which clearly would be A Bad Thing, but does the standard actually
>>> require it to be accepted?
>>
>> What's your line of reasoning here?  I don't see why such an
>> implementation could not compile the above but I also don't see how you
>> could be in doubt that the above should be accepted.
>>
>> (I have guesses about both of these but it seems wiser just to ask for
>> more detail.)
>
> Hypothetically,
> <errno.h> has:
>     #define EOF 42 /* Error on Ocelot Farm */
> and <stdio.h> has:
>     #define EOF (-1)
>
> Then the preprocessed expansion of the above source file has:
>     ...
>     #define EOF 42
>     ...
>     #define EOF (-1)
>     ...
> which violates C99 6.10.3p2.

Right, that's what I thought.  But merely defining EOF as positive in
errno.h is not what makes the implementation fail on this source -- it
is defining EOF in stdio.h without un-defining it first.  Since EOF in
errno.h is an extension, there's no way to know if it's really important
or not, so you can't assume that it can't be redefined.

> It's "obvious" that a program that has #include directives for any
> combination of standard headers and is otherwise legal is still legal
> (handwave meaning of "legal").  The question is, what clause of the
> standard does this implementation violate by rejecting the program?
> (I have no doubt that it violates the *intent* of the standard.)

Section 4 p6?  "a conforming hosted implementation shall accept any
strictly conforming program" and later "a conforming implementation may
have extensions (including additional library functions), provided they
do not alter the behavior of any strictly conforming program.[3]"

This does not alter your point because it's simple to write a program
that's not strictly confirming, but which your implementation would
reject.  Section 4 p3 helps here but it does not eliminate the problem
entirely.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#9354

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>>>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>>>>>> A stray thought wandered into my head this morning...
>>>>>>> 
>>>>>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>>>>>> E+capital-letter for error codes, what allows the Standard to also
>>>>>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>>>>>> it's the Standard, and it can do whatever it likes", that is.)
>>>>>>
>>>>>> Those macros are reserved for use by the implementation; EOF is
>>>>>> #defined by the implementation; there's no conflict. In principle,
>>>>>> EOF could even be a valid errno value.
>>>>>
>>>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>>>> that errno "is set to a positive error number by several library
>>>>> functions" but EOF must have a negative value (7.19.1p3).  It certainly
>>>>> seems as if setting errno to EOF would not be confirming to the spirit
>>>>> of the standard.
>>>>
>>>> If an implementation defined EOF with a positive value in <errno.h>, I
>>>> presume it would violate the standard, but what clause would it violate?
>>>>
>>>> Such an implementation would fail to compile this:
>>>>
>>>> #include <errno.h>
>>>> #include <stdio.h>
>>>> int main(void){}
>>>>
>>>> which clearly would be A Bad Thing, but does the standard actually
>>>> require it to be accepted?
>>>
>>> What's your line of reasoning here?  I don't see why such an
>>> implementation could not compile the above but I also don't see how you
>>> could be in doubt that the above should be accepted.
>>>
>>> (I have guesses about both of these but it seems wiser just to ask for
>>> more detail.)
>>
>> Hypothetically,
>> <errno.h> has:
>>     #define EOF 42 /* Error on Ocelot Farm */
>> and <stdio.h> has:
>>     #define EOF (-1)
>>
>> Then the preprocessed expansion of the above source file has:
>>     ...
>>     #define EOF 42
>>     ...
>>     #define EOF (-1)
>>     ...
>> which violates C99 6.10.3p2.
>
> Right, that's what I thought.  But merely defining EOF as positive in
> errno.h is not what makes the implementation fail on this source -- it
> is defining EOF in stdio.h without un-defining it first.  Since EOF in
> errno.h is an extension, there's no way to know if it's really important
> or not, so you can't assume that it can't be redefined.

<stdio.h> isn't required to undefine EOF before redefining it.  The
identifier EOF is reserved, so if a user program does this:

    #define EOF 42
    #include <stdio.h>

then that program's behavior is at best undefined.

>> It's "obvious" that a program that has #include directives for any
>> combination of standard headers and is otherwise legal is still legal
>> (handwave meaning of "legal").  The question is, what clause of the
>> standard does this implementation violate by rejecting the program?
>> (I have no doubt that it violates the *intent* of the standard.)
>
> Section 4 p6?  "a conforming hosted implementation shall accept any
> strictly conforming program" and later "a conforming implementation may
> have extensions (including additional library functions), provided they
> do not alter the behavior of any strictly conforming program.[3]"

I think you're assuming that this program:

#include <errno.h>
#include <stdio.h>
int main(void){}

is strictly conforming.  Of course it *should* be, but I'm arguing that
the reservation of the identifier EOF by both <stdio.h> and <errno.h>
creates an unintentional loophole, implying that it isn't.  It depends
on the implementation-defined choice of whether <errno.h> defines EOF.

> This does not alter your point because it's simple to write a program
> that's not strictly confirming, but which your implementation would
> reject.  Section 4 p3 helps here but it does not eliminate the problem
> entirely.

I think C99 7.1.3p1 is where the problem is:

    Each macro name in any of the following subclauses (including
    the future library directions) is reserved for use as specified
    if any of its associated headers is included; unless explicitly
    stated otherwise (see 7.1.4).

<stdio.h> reserves EOF because it explicitly defines it.  <errno.h>
reserves EOF because it's in the future library directions.
Contradiction.  (And as "Nobody" pointed out, the same applies to
EXIT_SUCCESS and EXIT_FAILURE.)

We can reasonably assume that explicit definitions override future
library directions, but the standard doesn't actually say so.

Of course this has very little practical importance.  No sane
implementer will define EOF, EXIT_SUCCESS, or EXIT_FAILURE in
<errno.h>.  The question is, if I release an implementation that
does this, will it fail horribly in the market because it's stupid
and unusable, or will it fail horribly in the market because it's
stupid, unusable, and non-conforming?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9370

On 8/13/2011 2:50 PM, Keith Thompson wrote:
> [...]
> I think you're assuming that this program:
>
> #include<errno.h>
> #include<stdio.h>
> int main(void){}
>
> is strictly conforming.  Of course it *should* be, but I'm arguing that
> the reservation of the identifier EOF by both<stdio.h>  and<errno.h>
> creates an unintentional loophole, implying that it isn't.  It depends
> on the implementation-defined choice of whether<errno.h>  defines EOF.

     7.1.2p4: "[...] However, if an identifier is declared or defined
in more than one header, the second and subsequent associated headers
may be included after the initial reference to the identifier."

     Assuming "initial reference" also covers the header's declaration
or definition, then both <stdio.h> and <errno.h> can be #include'd in
the same translation unit, and in either order.  Either must tolerate
the possible declaration of EOF by the other.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9377

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 8/13/2011 2:50 PM, Keith Thompson wrote:
>> [...]
>> I think you're assuming that this program:
>>
>> #include<errno.h>
>> #include<stdio.h>
>> int main(void){}
>>
>> is strictly conforming.  Of course it *should* be, but I'm arguing that
>> the reservation of the identifier EOF by both<stdio.h>  and<errno.h>
>> creates an unintentional loophole, implying that it isn't.  It depends
>> on the implementation-defined choice of whether<errno.h>  defines EOF.
>
>      7.1.2p4: "[...] However, if an identifier is declared or defined
> in more than one header, the second and subsequent associated headers
> may be included after the initial reference to the identifier."
>
>      Assuming "initial reference" also covers the header's declaration
> or definition, then both <stdio.h> and <errno.h> can be #include'd in
> the same translation unit, and in either order.  Either must tolerate
> the possible declaration of EOF by the other.

Good catch!

So having "#define EOF 42" in <errno.h> would be non-conforming, since
it would cause the above program to fail.

Well, maybe.  I suppose if the compiler merely issues a warning for an
inconsistently redefined macro, then it would still compile the program.
Warnings on strictly conforming programs are permitted.  *Sigh*.

And the wording for <errno.h> is a bit vague.  EDOM, EILSEQ, and ERANGE
are required to be positive, but (C99 7.5p4):

    Additional macro definitions, beginning with E and a digit
    or E and an uppercase letter, may also be specified by the
    implementation.

It doesn't say that these additional macro definitions must be
positive, that they must expand to integer constant expressions, or
that they're error codes.  They could even be function-like macros.
Or both <errno.h> and <stdio.h> could have "#define EOF (-1)".

Implementer sanity, not the Standard, is what saves us from such bizarre
things.  The only common variant I know of is that different E* macros
might have the same value.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9371

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>>>>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>>>>>>> A stray thought wandered into my head this morning...
>>>>>>>> 
>>>>>>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>>>>>>> E+capital-letter for error codes, what allows the Standard to also
>>>>>>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>>>>>>> it's the Standard, and it can do whatever it likes", that is.)
>>>>>>>
>>>>>>> Those macros are reserved for use by the implementation; EOF is
>>>>>>> #defined by the implementation; there's no conflict. In principle,
>>>>>>> EOF could even be a valid errno value.
>>>>>>
>>>>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>>>>> that errno "is set to a positive error number by several library
>>>>>> functions" but EOF must have a negative value (7.19.1p3).  It certainly
>>>>>> seems as if setting errno to EOF would not be confirming to the spirit
>>>>>> of the standard.
>>>>>
>>>>> If an implementation defined EOF with a positive value in <errno.h>, I
>>>>> presume it would violate the standard, but what clause would it violate?
>>>>>
>>>>> Such an implementation would fail to compile this:
>>>>>
>>>>> #include <errno.h>
>>>>> #include <stdio.h>
>>>>> int main(void){}
>>>>>
>>>>> which clearly would be A Bad Thing, but does the standard actually
>>>>> require it to be accepted?
>>>>
>>>> What's your line of reasoning here?  I don't see why such an
>>>> implementation could not compile the above but I also don't see how you
>>>> could be in doubt that the above should be accepted.
>>>>
>>>> (I have guesses about both of these but it seems wiser just to ask for
>>>> more detail.)
>>>
>>> Hypothetically,
>>> <errno.h> has:
>>>     #define EOF 42 /* Error on Ocelot Farm */
>>> and <stdio.h> has:
>>>     #define EOF (-1)
>>>
>>> Then the preprocessed expansion of the above source file has:
>>>     ...
>>>     #define EOF 42
>>>     ...
>>>     #define EOF (-1)
>>>     ...
>>> which violates C99 6.10.3p2.
>>
>> Right, that's what I thought.  But merely defining EOF as positive in
>> errno.h is not what makes the implementation fail on this source -- it
>> is defining EOF in stdio.h without un-defining it first.  Since EOF in
>> errno.h is an extension, there's no way to know if it's really important
>> or not, so you can't assume that it can't be redefined.
>
> <stdio.h> isn't required to undefine EOF before redefining it.  The
> identifier EOF is reserved, so if a user program does this:
>
>     #define EOF 42
>     #include <stdio.h>
>
> then that program's behavior is at best undefined.

Agreed, but I think we are talking at cross purposes.  I thought you
were saying that this daft implementation *must* fail to compile the
program you quoted.  I was just saying that it might not.  I don't think
there is any disagreement about the facts, but I may well have
misconstrued what you wrote.

>>> It's "obvious" that a program that has #include directives for any
>>> combination of standard headers and is otherwise legal is still legal
>>> (handwave meaning of "legal").  The question is, what clause of the
>>> standard does this implementation violate by rejecting the program?
>>> (I have no doubt that it violates the *intent* of the standard.)
>>
>> Section 4 p6?  "a conforming hosted implementation shall accept any
>> strictly conforming program" and later "a conforming implementation may
>> have extensions (including additional library functions), provided they
>> do not alter the behavior of any strictly conforming program.[3]"
>
> I think you're assuming that this program:
>
> #include <errno.h>
> #include <stdio.h>
> int main(void){}
>
> is strictly conforming.  Of course it *should* be, but I'm arguing that
> the reservation of the identifier EOF by both <stdio.h> and <errno.h>
> creates an unintentional loophole, implying that it isn't.  It depends
> on the implementation-defined choice of whether <errno.h> defines EOF.

How, then, is it strictly conforming?  I though that SCP must not depend
on anything implementation-defined.

>> This does not alter your point because it's simple to write a program
>> that's not strictly confirming, but which your implementation would
>> reject.  Section 4 p3 helps here but it does not eliminate the problem
>> entirely.
>
> I think C99 7.1.3p1 is where the problem is:
>
>     Each macro name in any of the following subclauses (including
>     the future library directions) is reserved for use as specified
>     if any of its associated headers is included; unless explicitly
>     stated otherwise (see 7.1.4).
>
> <stdio.h> reserves EOF because it explicitly defines it.  <errno.h>
> reserves EOF because it's in the future library directions.
> Contradiction.  (And as "Nobody" pointed out, the same applies to
> EXIT_SUCCESS and EXIT_FAILURE.)
>
> We can reasonably assume that explicit definitions override future
> library directions, but the standard doesn't actually say so.
>
> Of course this has very little practical importance.  No sane
> implementer will define EOF, EXIT_SUCCESS, or EXIT_FAILURE in
> <errno.h>.  The question is, if I release an implementation that
> does this, will it fail horribly in the market because it's stupid
> and unusable, or will it fail horribly in the market because it's
> stupid, unusable, and non-conforming?

I'm going with non-conforming for the moment.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#9376

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
[...]
>>>> Hypothetically,
>>>> <errno.h> has:
>>>>     #define EOF 42 /* Error on Ocelot Farm */
>>>> and <stdio.h> has:
>>>>     #define EOF (-1)
>>>>
>>>> Then the preprocessed expansion of the above source file has:
>>>>     ...
>>>>     #define EOF 42
>>>>     ...
>>>>     #define EOF (-1)
>>>>     ...
>>>> which violates C99 6.10.3p2.
>>>
>>> Right, that's what I thought.  But merely defining EOF as positive in
>>> errno.h is not what makes the implementation fail on this source -- it
>>> is defining EOF in stdio.h without un-defining it first.  Since EOF in
>>> errno.h is an extension, there's no way to know if it's really important
>>> or not, so you can't assume that it can't be redefined.
>>
>> <stdio.h> isn't required to undefine EOF before redefining it.  The
>> identifier EOF is reserved, so if a user program does this:
>>
>>     #define EOF 42
>>     #include <stdio.h>
>>
>> then that program's behavior is at best undefined.
>
> Agreed, but I think we are talking at cross purposes.  I thought you
> were saying that this daft implementation *must* fail to compile the
> program you quoted.  I was just saying that it might not.  I don't think
> there is any disagreement about the facts, but I may well have
> misconstrued what you wrote.

The only program an implementation *must* fail to compile is one with a
#error directive.

The above 2-line program will trigger a diagnostic if <stdio.h> doesn't
undefine EOF before defining it.  There's no rule that says it should
undefine it or that it shouldn't.  (It's probably better QoI-wise if it
doesn't, so that bad code like the above *will* trigger a diagnostic.)

[...]

>> I think you're assuming that this program:
>>
>> #include <errno.h>
>> #include <stdio.h>
>> int main(void){}
>>
>> is strictly conforming.  Of course it *should* be, but I'm arguing that
>> the reservation of the identifier EOF by both <stdio.h> and <errno.h>
>> creates an unintentional loophole, implying that it isn't.  It depends
>> on the implementation-defined choice of whether <errno.h> defines EOF.
>
> How, then, is it strictly conforming?  I though that SCP must not depend
> on anything implementation-defined.

It's not; that was my point.  I inferred (perhaps wrongly) that you were
assuming that it is.  On the other hand, I now think it is; see my
response to Eric Sosman (as soon as I write it).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9378

On 8/13/2011 8:57 PM, Keith Thompson wrote:
> [...] see my
> response to Eric Sosman (as soon as I write it).

	Waitin',
	Waitin',
	I've been waitin'.
	Waitin',
	Waitin'
	All my life.
	That light keeps on
	Hiding from me,
	But it someday
	Just might
	Bless my sight.
	Waitin',
	Waitin',
	Waitin'.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9381

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 8/13/2011 8:57 PM, Keith Thompson wrote:
>> [...] see my
>> response to Eric Sosman (as soon as I write it).
>
> 	Waitin',
> 	Waitin',
> 	I've been waitin'.
> 	Waitin',
> 	Waitin'
> 	All my life.
> 	That light keeps on
> 	Hiding from me,
> 	But it someday
> 	Just might
> 	Bless my sight.
> 	Waitin',
> 	Waitin',
> 	Waitin'.

Sheesh, it was 7 minutes!  8-)}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9932

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>>>>> On 08/12/2011 12:04 PM, Kenneth Brody wrote:
>>>>>>>> A stray thought wandered into my head this morning...
>>>>>>>> 
>>>>>>>> Given that 7.5p4 reserves macros that begin with E+digit or
>>>>>>>> E+capital-letter for error codes, what allows the Standard to also
>>>>>>>> define EOF in a manner unrelated to <errno.h>?  (Aside from "duh,
>>>>>>>> it's the Standard, and it can do whatever it likes", that is.)
>>>>>>>
>>>>>>> Those macros are reserved for use by the implementation; EOF is
>>>>>>> #defined by the implementation; there's no conflict. In principle,
>>>>>>> EOF could even be a valid errno value.
>>>>>>
>>>>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>>>>> that errno "is set to a positive error number by several library
>>>>>> functions" but EOF must have a negative value (7.19.1p3).  It certainly
>>>>>> seems as if setting errno to EOF would not be confirming to the spirit
>>>>>> of the standard.
>>>>>
>>>>> If an implementation defined EOF with a positive value in <errno.h>, I
>>>>> presume it would violate the standard, but what clause would it violate?
>>>>>
>>>>> Such an implementation would fail to compile this:
>>>>>
>>>>> #include <errno.h>
>>>>> #include <stdio.h>
>>>>> int main(void){}
>>>>>
>>>>> which clearly would be A Bad Thing, but does the standard actually
>>>>> require it to be accepted?
>>>>
>>>> What's your line of reasoning here?  I don't see why such an
>>>> implementation could not compile the above but I also don't see how you
>>>> could be in doubt that the above should be accepted.
>>>>
>>>> (I have guesses about both of these but it seems wiser just to ask for
>>>> more detail.)
>>>
>>> Hypothetically,
>>> <errno.h> has:
>>>     #define EOF 42 /* Error on Ocelot Farm */
>>> and <stdio.h> has:
>>>     #define EOF (-1)
>>>
>>> Then the preprocessed expansion of the above source file has:
>>>     ...
>>>     #define EOF 42
>>>     ...
>>>     #define EOF (-1)
>>>     ...
>>> which violates C99 6.10.3p2.
>>
>> Right, that's what I thought.  But merely defining EOF as positive in
>> errno.h is not what makes the implementation fail on this source -- it
>> is defining EOF in stdio.h without un-defining it first.  Since EOF in
>> errno.h is an extension, there's no way to know if it's really important
>> or not, so you can't assume that it can't be redefined.
>
> <stdio.h> isn't required to undefine EOF before redefining it.  The
> identifier EOF is reserved, so if a user program does this:
>
>     #define EOF 42
>     #include <stdio.h>
>
> then that program's behavior is at best undefined.
>
>>> It's "obvious" that a program that has #include directives for any
>>> combination of standard headers and is otherwise legal is still legal
>>> (handwave meaning of "legal").  The question is, what clause of the
>>> standard does this implementation violate by rejecting the program?
>>> (I have no doubt that it violates the *intent* of the standard.)
>>
>> Section 4 p6?  "a conforming hosted implementation shall accept any
>> strictly conforming program" and later "a conforming implementation may
>> have extensions (including additional library functions), provided they
>> do not alter the behavior of any strictly conforming program.[3]"
>
> I think you're assuming that this program:
>
> #include <errno.h>
> #include <stdio.h>
> int main(void){}
>
> is strictly conforming.  Of course it *should* be, but I'm arguing that
> the reservation of the identifier EOF by both <stdio.h> and <errno.h>
> creates an unintentional loophole, implying that it isn't.  It depends
> on the implementation-defined choice of whether <errno.h> defines EOF.
>
>> This does not alter your point because it's simple to write a program
>> that's not strictly confirming, but which your implementation would
>> reject.  Section 4 p3 helps here but it does not eliminate the problem
>> entirely.
>
> I think C99 7.1.3p1 is where the problem is:
>
>     Each macro name in any of the following subclauses (including
>     the future library directions) is reserved for use as specified
>     if any of its associated headers is included; unless explicitly
>     stated otherwise (see 7.1.4).
>
> <stdio.h> reserves EOF because it explicitly defines it.  <errno.h>
> reserves EOF because it's in the future library directions.
> Contradiction.  (And as "Nobody" pointed out, the same applies to
> EXIT_SUCCESS and EXIT_FAILURE.)  [snip elaboration]

The quoted text isn't the cause of a problem but rather its
resolution.  This paragraph requires, for example, if EOF is
(also) defined in errno.h, it must meet _all_ the requirements
for EOF -- "is reserved for use as specified", and that means all
specifications, including those described for stdio.h.  In fact
it makes a stronger statement, to wit:  if errno.h is included,
then EOF is reserved whether stdio.h is included or not.  Not
guaranteed to be defined, but still reserved.

[toc] | [prev] | [next] | [standalone]

#9314

On 08/12/2011 07:12 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> Those macros are reserved for use by the implementation; EOF is #defined
>> by the implementation; there's no conflict. In principle, EOF could even
>> be a valid errno value.
> 
> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
> that errno "is set to a positive error number by several library

Sorry - I'd forgotten that the errno values were required to be
positive. It's not a fact I've ever had any need to know. In fact, it's
not clear to me what advantage there is in requiring them to be positive.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#9320

On Fri, 12 Aug 2011 20:51:40 -0400, James Kuyper wrote:

>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>> that errno "is set to a positive error number by several library
> 
> Sorry - I'd forgotten that the errno values were required to be
> positive. It's not a fact I've ever had any need to know. In fact, it's
> not clear to me what advantage there is in requiring them to be positive.

One possibility: the program can use negative values for its own purposes,
without risking a conflict with values defined by <errno.h>.

[toc] | [prev] | [next] | [standalone]

#9345

Nobody <nobody@nowhere.com> writes:

> On Fri, 12 Aug 2011 20:51:40 -0400, James Kuyper wrote:
>
>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>> that errno "is set to a positive error number by several library
>> 
>> Sorry - I'd forgotten that the errno values were required to be
>> positive. It's not a fact I've ever had any need to know. In fact, it's
>> not clear to me what advantage there is in requiring them to be positive.
>
> One possibility: the program can use negative values for its own purposes,
> without risking a conflict with values defined by <errno.h>.

Absolutely.  That's why I said "at least not in a useful way".  The
program can do that but these extended error numbers can be set by
library functions.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#9442

On 8/12/2011 8:51 PM, James Kuyper wrote:
> On 08/12/2011 07:12 PM, Ben Bacarisse wrote:
>> James Kuyper<jameskuyper@verizon.net>  writes:
> ....
>>> Those macros are reserved for use by the implementation; EOF is #defined
>>> by the implementation; there's no conflict. In principle, EOF could even
>>> be a valid errno value.
>>
>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>> that errno "is set to a positive error number by several library
>
> Sorry - I'd forgotten that the errno values were required to be
> positive. It's not a fact I've ever had any need to know. In fact, it's
> not clear to me what advantage there is in requiring them to be positive.

Furrfu, I post some random thought on Friday, and I come back on Monday to 
find a huge thread discussing it.

Anyway, does the Standard say that E* macros must be positive?  All I see in 
that quote is that errno "is set to a positive error number".  (My copy of 
N1256 says "errno may be set to nonzero by a library function call", without 
mention of "positive error number".  Was this changed in the final wording?) 
  Can <errno.h> define non-positive values, as long as errno is never set to 
that value?  (Hey, this started with an insane implementation using EOF as 
an error number.  Perhaps the implementer was a bit more insane than we 
originally thought.  Though I don't see "#define ENONE 0" as too weird.)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#9445

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 8/12/2011 8:51 PM, James Kuyper wrote:
>> On 08/12/2011 07:12 PM, Ben Bacarisse wrote:
>>> James Kuyper<jameskuyper@verizon.net>  writes:
>> ....
>>>> Those macros are reserved for use by the implementation; EOF is #defined
>>>> by the implementation; there's no conflict. In principle, EOF could even
>>>> be a valid errno value.
>>>
>>> I'm not sure it could be (or at least not in a useful way).  7.5p3 says
>>> that errno "is set to a positive error number by several library
>>
>> Sorry - I'd forgotten that the errno values were required to be
>> positive. It's not a fact I've ever had any need to know. In fact, it's
>> not clear to me what advantage there is in requiring them to be positive.
>
> Furrfu, I post some random thought on Friday, and I come back on
> Monday to find a huge thread discussing it.
>
> Anyway, does the Standard say that E* macros must be positive?  All I
> see in that quote is that errno "is set to a positive error number".
> (My copy of N1256 says "errno may be set to nonzero by a library
> function call", without mention of "positive error number".  Was this
> changed in the final wording?) Can <errno.h> define non-positive
> values, as long as errno is never set to that value?  (Hey, this
> started with an insane implementation using EOF as an error number.
> Perhaps the implementer was a bit more insane than we originally
> thought.  Though I don't see "#define ENONE 0" as too weird.)

(I think I already mentioned this.)

It requires that EDOM, EILSEQ, and ERANGE must be distinct and positive.

It says nothing specific about any other implementation-defined E*
macros defined in <errno.h> -- not even that they're error codes.
(Remember, we're talking about hypothetical insane implementations.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web