[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Random thought -- EOF and errno

Kenneth Brody

8/12/2011 4:05:00 PM

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

James Kuyper

8/12/2011 4:28:00 PM

0

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.

Seebs

8/12/2011 6:38:00 PM

0

On 2011-08-12, Kenneth Brody <kenbrody@spamcop.net> 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.)

> Just wondering.

Pretty much that. Things that are "reserved" are reserved for future
expansion of the standard, and don't have anything to do with what the
standard already does.

Sort of like the way the standard can, while already having some capital
letters in use for printf format characters, reserve capital letters for
implementation extensions.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Ben Bacarisse

8/12/2011 11:13:00 PM

0

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.

Keith Thompson

8/12/2011 11:30:00 PM

0

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.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Bacarisse

8/13/2011 12:27:00 AM

0

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.

James Kuyper

8/13/2011 12:52:00 AM

0

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

Keith Thompson

8/13/2011 1:29:00 AM

0

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.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

John Doe

8/13/2011 4:55:00 AM

0

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

John Doe

8/13/2011 5:00:00 AM

0

On Fri, 12 Aug 2011 12:04:43 -0400, 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.)

Note that the same applies to EXIT_SUCCESS and EXIT_FAILURE.

Ben Bacarisse

8/13/2011 1:38:00 PM

0

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.