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

Groups > comp.lang.c > #400004 > unrolled thread

Re: Constants and undefined behavior

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
    Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
    Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
    Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700

#400004 — Re: Constants and undefined behavior

David Brown <david.brown@hesbynett.no> writes:
> On 11/06/2026 17:34, Janis Papanagnou wrote:
>> On 2026-06-11 08:56, David Brown wrote:
>>> On 10/06/2026 23:47, Keith Thompson wrote:
>>>> [...]
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>>      bool keep_going = true;
>>>>      while (keep_going) {
>>>>          keep_going = true;
>>>>      }
>>>>      puts("never reached");
>>>> }
>>>>
>>>> [...]
>>>
>>> [...]
>>>
>>> The loop might originally have contained source code, but become
>>> empty through pre-processing, or from other compiler
>>> transformations (such as the compiler seeing that the "keep_going"
>>> variable is not volatile and its value is never used, so
>>> assignments to it can be elided, or moving other things outside the
>>> loop body).
>>>
>>> A programmer /could/ write the "keep_going" loop you gave, and
>>> mistakenly believe it to be infinite.  But is it likely? 
>>
>> I think we should not make any assumptions about the "creativity" of
>> a programmer ("C" or else). - Semantics should be well defined, and
>> then clear to the programmer.
>
> I think the semantics of this "loops can be assumed to terminate" are
> clearly defined in the standard.  I agree that the details might not
> be known to all C programmers, but I think they are only relevant in a
> very small number of cases.

I disagree that the semantics are clearly defined.  N3220 6.8.6.1p4
is specified in terms of what an implementation may "assume", not in
terms of the semantics of the program.  One can conclude that this
means that the program has undefined behavior if the assumption is
violated, but that's not directly stated.  I don't know how many C
programmers know the standard well enough to reach that conclusion.
I'm not even 100% sure it's accurate.

The permission was added in C11 with little fanfare.  It's not
mentioned in the list of major changes in the C11 Foreword.
The cases where it applies may be rarer than I had assumed, but
it at least has the potential to break existing code that was well
defined in C99.

The rationale is to provide more opportunities for optimization,
but it's not at all clear (at least to me) that it's particularly
successful.  If cases where it can cause problems are rare, then
presumably cases where it's actually useful are rare.  (That may
be an oversimplification.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [next] | [standalone]

#400021

On 12/06/2026 21:27, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/06/2026 17:34, Janis Papanagnou wrote:
>>> On 2026-06-11 08:56, David Brown wrote:
>>>> On 10/06/2026 23:47, Keith Thompson wrote:
>>>>> [...]
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>>       bool keep_going = true;
>>>>>       while (keep_going) {
>>>>>           keep_going = true;
>>>>>       }
>>>>>       puts("never reached");
>>>>> }
>>>>>
>>>>> [...]
>>>>
>>>> [...]
>>>>
>>>> The loop might originally have contained source code, but become
>>>> empty through pre-processing, or from other compiler
>>>> transformations (such as the compiler seeing that the "keep_going"
>>>> variable is not volatile and its value is never used, so
>>>> assignments to it can be elided, or moving other things outside the
>>>> loop body).
>>>>
>>>> A programmer /could/ write the "keep_going" loop you gave, and
>>>> mistakenly believe it to be infinite.  But is it likely?
>>>
>>> I think we should not make any assumptions about the "creativity" of
>>> a programmer ("C" or else). - Semantics should be well defined, and
>>> then clear to the programmer.
>>
>> I think the semantics of this "loops can be assumed to terminate" are
>> clearly defined in the standard.  I agree that the details might not
>> be known to all C programmers, but I think they are only relevant in a
>> very small number of cases.
> 
> I disagree that the semantics are clearly defined.  N3220 6.8.6.1p4
> is specified in terms of what an implementation may "assume", not in
> terms of the semantics of the program.  One can conclude that this
> means that the program has undefined behavior if the assumption is
> violated, but that's not directly stated.  I don't know how many C
> programmers know the standard well enough to reach that conclusion.
> I'm not even 100% sure it's accurate.
> 
> The permission was added in C11 with little fanfare.  It's not
> mentioned in the list of major changes in the C11 Foreword.
> The cases where it applies may be rarer than I had assumed, but
> it at least has the potential to break existing code that was well
> defined in C99.
> 
> The rationale is to provide more opportunities for optimization,
> but it's not at all clear (at least to me) that it's particularly
> successful.  If cases where it can cause problems are rare, then
> presumably cases where it's actually useful are rare.  (That may
> be an oversimplification.)
> 

I agree on that last point.  I doubt if any code would suffer if the 
paragraph were removed entirely from the standard.  And while I also 
don't think much real-world code is at risk of problems from its 
inclusion in the standard, as long as there is some risk of problems 
with existing correct code, or some risk of confusion or 
misunderstanding on the part of programmers reading the standard, then 
it would be better if that paragraph had not been added to the standard 
at all.

[toc] | [prev] | [next] | [standalone]

#400025

In article <110hmi7$2e85g$1@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>David Brown <david.brown@hesbynett.no> writes:
>> On 11/06/2026 17:34, Janis Papanagnou wrote:
>>> On 2026-06-11 08:56, David Brown wrote:
>>>> On 10/06/2026 23:47, Keith Thompson wrote:
>>>>> [...]
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>>      bool keep_going = true;
>>>>>      while (keep_going) {
>>>>>          keep_going = true;
>>>>>      }
>>>>>      puts("never reached");
>>>>> }
>>>>>
>>>>> [...]
>>>>
>>>> [...]
>>>>
>>>> The loop might originally have contained source code, but become
>>>> empty through pre-processing, or from other compiler
>>>> transformations (such as the compiler seeing that the "keep_going"
>>>> variable is not volatile and its value is never used, so
>>>> assignments to it can be elided, or moving other things outside the
>>>> loop body).
>>>>
>>>> A programmer /could/ write the "keep_going" loop you gave, and
>>>> mistakenly believe it to be infinite.  But is it likely? 
>>>
>>> I think we should not make any assumptions about the "creativity" of
>>> a programmer ("C" or else). - Semantics should be well defined, and
>>> then clear to the programmer.
>>
>> I think the semantics of this "loops can be assumed to terminate" are
>> clearly defined in the standard.  I agree that the details might not
>> be known to all C programmers, but I think they are only relevant in a
>> very small number of cases.
>
>I disagree that the semantics are clearly defined.  N3220 6.8.6.1p4
>is specified in terms of what an implementation may "assume", not in
>terms of the semantics of the program.  One can conclude that this
>means that the program has undefined behavior if the assumption is
>violated, but that's not directly stated.  I don't know how many C
>programmers know the standard well enough to reach that conclusion.
>I'm not even 100% sure it's accurate.
>
>The permission was added in C11 with little fanfare.  It's not
>mentioned in the list of major changes in the C11 Foreword.
>The cases where it applies may be rarer than I had assumed, but
>it at least has the potential to break existing code that was well
>defined in C99.

Another example of something that was previously well-defined
and is now UB, I guess.  :-/

>The rationale is to provide more opportunities for optimization,
>but it's not at all clear (at least to me) that it's particularly
>successful.  If cases where it can cause problems are rare, then
>presumably cases where it's actually useful are rare.  (That may
>be an oversimplification.)

I'm not sure that's the rationale: rather, it's to guarantee
forward progress.  Again, that's not really the language's
purview.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#401169

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@hesbynett.no> writes:
[...]
>> I think the semantics of this "loops can be assumed to terminate"
>> are clearly defined in the standard.  [...]
>
> I disagree that the semantics are clearly defined.  N3220 6.8.6.1p4
> is specified in terms of what an implementation may "assume", not in
> terms of the semantics of the program.

It isn't obvious that the semantics of "may be assumed to terminate"
is even well defined by the text of the C standard;  it certainly is
not clearly defined.

> One can conclude that this
> means that the program has undefined behavior if the assumption is
> violated, but that's not directly stated.  I don't know how many C
> programmers know the standard well enough to reach that conclusion.
> I'm not even 100% sure it's accurate.
>
> The permission was added in C11 with little fanfare.  It's not
> mentioned in the list of major changes in the C11 Foreword.
> The cases where it applies may be rarer than I had assumed, but
> it at least has the potential to break existing code that was well
> defined in C99.
>
> The rationale is to provide more opportunities for optimization,
> but it's not at all clear (at least to me) that it's particularly
> successful.  If cases where it can cause problems are rare, then
> presumably cases where it's actually useful are rare.  (That may
> be an oversimplification.)

If someone is counting votes my vote is to remove this rule from
the C standard.  If there were a compiler option to act as though
this rule were not in force I would always use that option.  It's
worse than useless.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web