Ben Bacarisse
8/13/2011 1:38:00 PM
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.