Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Is C ready to become a safer language?
Date: Sun, 11 Feb 2024 00:12:58 -0800
Organization: None to speak of
Lines: 69
Message-ID: <87a5o7ber9.fsf@nosuchdomain.example.com>
References: <uq1jnk$1qebo$2@dont-email.me> <87jznfh7p6.fsf@nosuchdomain.example.com> <865xyw62av.fsf@linuxsc.com> <877cjbdfg3.fsf@nosuchdomain.example.com> <86frxz4g9l.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="a3ea5551d1916ca86f611a52355c117b"; logging-data="954126"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18OQaSKYnTjiI1VWiKUOt+R"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:8kdETh+9j8u8ahJHZ1JUINbmNAU= sha1:YFxj+GIUlczwRFUT+ZOTE/5vqnA=
Xref: csiph.com comp.lang.c:382313

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [snip discussion of a program that divides by zero]
>>
>>> An implementation can refuse to translate the program, but not
>>> because undefined behavior occurs.  The undefined behavior here
>>> happens only when the program is executed, but just compiling the
>>> program doesn't do that.  No execution, no undefined behavior.
>>> Still the program may be rejected, because it is not strictly
>>> conforming (by virtue of having output depend on the undefined
>>> behavior if the program is ever run).
>>
>> Just to be clear, would you say that a conforming hosted implementation
>> may reject this program:
>>
>> #include <limits.h>
>> #include <stdio.h>
>> int main(void) {
>>     printf("INT_MAX = %d\n", INT_MAX);
>> }
>>
>> solely because it's not strictly conforming?
>
> My understanding of the C standard is that a hosted implementation
> may choose not to accept the above program and still be conforming,
> because this program is not strictly conforming.  (Please assume
> subsequent remarks always refer to implementations that are both
> hosted and conforming.)
>
> Also, assuming we have ruled out cases involving #error, a conforming
> implementation may choose not to accept a given program if and only if
> the program is not strictly conforming.  Being strictly conforming is
> the only criterion that matters (again assuming there is no #error) in
> deciding whether an implementation may choose not to accept the
> program in question.
>
> I'm guessing that what you mean by "may reject" is the same as what
> I mean by "may choose not to accept".  I'd like to know if you think
> that's right, or if you think there is some difference between the
> two.  (My intention is that the two phrases have the same meaning.)
>
> Does the above adequately address the question you want answered?

I'm not sure.  As I recall, I gave up on trying to understand what you
think "accept" means.

N1570 5.1.2.3p6:

    A program that is correct in all other aspects, operating on correct
    data, containing unspecified behavior shall be a correct program and
    act in accordance with 5.1.2.3.

Does that not apply to the program above?  How can it do so if it's
rejected (or not "accepted")?

The same paragraph says that "A *conforming hosted implementation* shall
accept any strictly conforming program".  Are you reading that as
implying that *only* strictly conforming programs must be accepted?

As a practical matter, an implementation that accepts *only* strictly
conforming programs would be very nearly useless.  I don't see anything
in the standard that says a program can be rejected purely because it's
not strictly conforming, and I don't believe that was the intent.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */