Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #383931
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Is C ready to become a safer language? |
| Date | 2024-03-23 10:35 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <865xxclukk.fsf@linuxsc.com> (permalink) |
| References | (3 earlier) <877cjbdfg3.fsf@nosuchdomain.example.com> <86frxz4g9l.fsf@linuxsc.com> <87a5o7ber9.fsf@nosuchdomain.example.com> <86zfw62kd8.fsf@linuxsc.com> <87sf1p5p3h.fsf@nosuchdomain.example.com> |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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:
>>>
>>>> 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:
>
> [CORRECTION: 3p4]
>
>>> 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.
>>
>> My understanding of the C standard is that 'shall accept' is
>> meant in the sense of 'shall use its best efforts to complete
>> translation phases 1 through 8 successfully and produce an
>> executable'.
>
> That sounds reasonable. I wish the standard actually defined
> "accept".
>
>> Where you say "5.1.2.3p6:" I expect you mean "4p3".
>
> Yes.
>
>> Where you say "the same paragraph" I expect you mean "4p6".
>
> Yes.
>
>> The word "reject" does not appear in the C standard. In my own
>> writing I am trying henceforth to use "accept" exclusively and
>> not use "reject". For the safe of discussion I can take "reject"
>> to mean the logical complement of "accept", which is to say a
>> program is either accepted or rejected, never both and never
>> neither. Does that last sentence match your own usage?
>
> Yes, "reject" means "not accept". There might be some nuance that
> that definition misses, so I'll try to avoid using the word "reject"
> in this discussion.
>
>> The C standard has only one place where a statement is made about
>> accepting a program, saying in 4p6 that implementations shall
>> accept any strictly conforming program; no other paragraph in the
>> standard mentions accepting a program. Given that, it's hard for
>> me to understand how someone could read the standard as saying
>> anything other than that a program must be accepted if it is
>> strictly conforming, but if the program is not strictly conforming
>> then there is no requirement that it be accepted. In short form, a
>> program must be accepted if and only if it is strictly conforming.
>> Does that summary mean something different than your phrase "*only*
>> strictly conforming programs must be accepted"?. My understanding
>> of the C standard is that strictly conforming programs must be
>> accepted, but implementations are not required to accept any
>> program that is not strictly conforming.
>
> Certainly a conforming implementation must accept any strictly
> conforming program (insert handwaving about capacity limits).
No handwaving needed. If "accept" is taken to mean 'shall use its
best efforts to ...', etc., there is no problem with those efforts
failing for reasons outside the implementation's control.
> I can understand how one might read that requirement as implying
> that an implementation need not accept any program that is not
> strictly conforming. I don't read it that way.
James Kuyper has said
The standard never talks about rejection. It requires that
"A conforming hosted implementation shall accept any
strictly conforming program.". No such requirement applies
to any program which is not strictly conforming. (4p6)
Clearly James thinks implementations are free not to accept any
program that is not strictly conforming. Do you think James is
wrong?
In an earlier posting you said
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.
What is the basis for that belief? Can you point to some passage in
the C standard, or some other materials, that supports it? Or do
you believe it just because you think no sensible person could
intend otherwise?
>> In response to your question about 4p3, the short answer is that
>> any non-strictly-conforming program that an implementation chooses
>> not to accept is not correct in all other aspects, so 4p3 does not
>> apply. If you want to talk about that further we should split that
>> off into a separate thread, because 4p3 has nothing to do with
>> program acceptance.
>
> I say it does. Under 4p3, the above program (that prints the value
> of INT_MAX) is a "correct program", so it must "act in accordance
> with 5.1.2.3". It cannot do so unless it is first accepted.
It's a circular argument. You assume that a non-strictly conforming
program does not violate the requirement that the program be "correct
in all other aspects" and then conclude that the program is correct.
You're assuming the very thing you set out to prove.
What is the purpose of 4p3? What is the motivation for including it
in the C standard? Do you think it's there only to make programs
like the INT_MAX program above be non-rejectable? What else does it
do? What do you think is meant by "act in accordance with 5.1.2.3"?
Besides the C standard, what other materials or resources have you
consulted in forming your opinions or drawing your conclusions?
Suppose 4p3 were not included in the C standard. How would that
change the C language? What would be different, besides questions
like the one we are considering now?
The C90 standard does not include any requirement along the lines of
4p3 in C99 and later. Does that mean C90 is different in some way?
What prompted the insertion of 4p3 into C99? What efforts have you
made to investigate that? Or have you not made any?
> You're saying that the correctness of a program can depend on
> whether an implementation chooses to accept it. I disagree.
Certainly whether a program is strictly conforming CAN make a
difference in whether a program is "correct in all other aspects"
with respect to whether 4p3 applies. I have posted an example
actually observed in the behaviors of gcc and clang (having to do
with the size of an array type). The example violates no
constraints or syntax rules, has no undefined behavior, and uses
only language features specified in the C standard. Despite all
that clang rejects it. The only basis for clang's rejecting the
program is that the program is not strictly conforming. So one way
or another 4p3 is not relevant.
> An implementation that does not accept the above program is not
> conforming because the implementation violates 4p3.
Your reasoning the 4p3 applies here is flawed, because it's a
circular argument. More compellingly, you haven't presented any
evidence that 4p3 is meant to be relevant to the question of
acceptance. I know you think it is, and you have offered some
reasoning why it should be, but your explanations are not evidence.
What leads you to believe that members of the ISO C committee look
at this issue the same way you do? Have you made any effort to
answer that question?
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 01:01 -0300
Re: Is C ready to become a safer language? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 04:40 +0000
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 05:00 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:20 -0300
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 17:02 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:17 -0300
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:19 -0300
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:57 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:45 -0800
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:56 -0300
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 04:58 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 21:33 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 20:59 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 09:17 +0100
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:48 -0300
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 14:42 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 16:25 +0100
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:15 -0300
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 21:42 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:04 -0800
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 16:14 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:32 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:19 +0100
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 07:46 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 09:33 +0100
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 10:03 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 11:17 +0100
Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 10:24 +0000
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 11:24 +0000
Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:28 +0000
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 14:04 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:03 +0100
ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 16:01 +0000
Re: ustent on that. David Brown <david.brown@hesbynett.no> - 2024-02-09 18:00 +0100
Re: ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-10 01:20 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-09 12:45 +0000
Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:01 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:08 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:48 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:14 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:28 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 20:15 +0100
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 02:28 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:15 -0800
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 23:22 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 00:12 -0800
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 23:48 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 15:28 -0800
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 10:35 -0700
Re: Is C ready to become a safer language? Richard Kettlewell <invalid@invalid.invalid> - 2024-02-08 15:37 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:25 -0300
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 16:30 +0000
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 17:59 -0800
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-10 20:22 +0000
Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-10 21:30 +0000
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 21:49 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-10 20:44 -0300
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:06 +0100
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:43 -0300
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:33 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-12 11:32 +0100
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 00:02 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:39 -0800
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 02:46 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:24 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 15:06 +0100
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 18:32 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:15 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:31 -0800
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:57 -0300
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:47 -0800
Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-11 00:40 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 01:06 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:51 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:27 +0100
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 19:54 -0800
Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-13 06:22 +0000
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 11:01 +0000
Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 11:31 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:38 +0000
Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 13:23 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 14:17 +0000
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 22:21 -0800
csiph-web