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


Groups > comp.lang.c > #9354

Re: Random thought -- EOF and errno

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>

Show all headers | View raw


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


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