Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Random thought -- EOF and errno |
| Date | 2011-08-13 11:50 -0700 |
| Organization | None to speak of |
| Message-ID | <lnzkjd403q.fsf@nuthaus.mib.org> (permalink) |
| References | (2 earlier) <0.03d9cfe7c11f159d377c.20110813001241BST.87k4aijkba.fsf@bsb.me.uk> <lnty9m5htr.fsf@nuthaus.mib.org> <0.06274cbd79e04c20808d.20110813012700BST.87ei0qjgvf.fsf@bsb.me.uk> <lnpqka5cc1.fsf@nuthaus.mib.org> <0.83adf5802e654f78a515.20110813143800BST.87d3g9ig93.fsf@bsb.me.uk> |
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web