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

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

On Undefined Behavior

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

Contents

  On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-01 22:54 +0100
    Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-02 00:26 +0200
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-01 23:57 +0100
      Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 22:56 +0000
        Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-03 20:48 +0200
        Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 14:38 +0100
          Re: On Undefined Behaviour Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 21:42 +0000
            Re: On Undefined Behaviour candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2026-01-07 06:40 +0000
          Re: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-04 16:58 -0500
            Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-05 08:49 +0100
    Re: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-01 17:49 -0500
    Re: On Undefined Behavior antispam@fricas.org (Waldek Hebisch) - 2026-01-02 05:53 +0000
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-02 17:38 +0100
        Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-03 13:30 +0100
    Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-02 10:31 +0100
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-02 17:51 +0100
        Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-03 13:42 +0100
          Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-03 14:42 +0100
            Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-03 17:51 +0100
              Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 00:20 +0100
    Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 22:52 +0000
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-03 23:47 +0100
        Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-04 12:58 +0100
    Re: On Undefined Behavior Andrey Tarasevich <noone@noone.net> - 2026-01-03 07:53 -0800
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 00:15 +0100
        NULL dereference in embedded [was: On Undefined Behavior] highcrew <high.crew3868@fastmail.com> - 2026-01-04 00:25 +0100
          Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-03 18:59 -0500
            Re: NULL dereference in embedded [was: On Undefined Behavior] scott@slp53.sl.home (Scott Lurndal) - 2026-01-04 15:51 +0000
              Re: NULL dereference in embedded [was: On Undefined Behavior] David Brown <david.brown@hesbynett.no> - 2026-01-05 08:55 +0100
          Re: NULL dereference in embedded [was: On Undefined Behavior] Andrey Tarasevich <noone@noone.net> - 2026-01-03 17:24 -0800
            Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 02:19 +0000
              Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-03 21:31 -0500
                Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 04:52 +0000
                  Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-04 13:00 -0500
                    Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 21:22 +0000
                      Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-04 16:53 -0500
                        Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-05 00:16 +0000
                          Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 06:41 -0500
                    Re: NULL dereference in embedded [was: On Undefined Behavior] David Brown <david.brown@hesbynett.no> - 2026-01-05 09:07 +0100
              Re: NULL dereference in embedded [was: On Undefined Behavior] scott@slp53.sl.home (Scott Lurndal) - 2026-01-04 15:56 +0000
            Re: NULL dereference in embedded [was: On Undefined Behavior] Andrey Tarasevich <noone@noone.net> - 2026-01-03 18:44 -0800
          Re: NULL dereference in embedded [was: On Undefined Behavior] David Brown <david.brown@hesbynett.no> - 2026-01-04 17:16 +0100
            Re: NULL dereference in embedded [was: On Undefined Behavior] antispam@fricas.org (Waldek Hebisch) - 2026-01-06 13:08 +0000
              Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 21:59 +0000
              Re: NULL dereference in embedded [was: On Undefined Behavior] Andrey Tarasevich <noone@noone.net> - 2026-01-07 20:48 -0800
                Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-08 23:56 +0000
    Re: On Undefined Behavior Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 23:14 +0000
    Re: On Undefined Behavior "Paul J. Lucas" <paul@lucasmail.org> - 2026-01-03 17:10 -0800
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 12:51 +0100
        Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-05 15:39 +0100
          Re: On Undefined Behavior "Paul J. Lucas" <paul@lucasmail.org> - 2026-01-06 18:08 -0800
            Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-07 11:25 +0100
            Re: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-07 06:31 -0500
            Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-07 14:10 +0200
    Re: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-09 01:42 -0800
      Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-09 14:36 +0200
        Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-09 20:14 +0000
          Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-10 18:19 +0200
          Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-10 18:41 +0200
            Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-13 23:31 +0000
              Re: On Undefined Behavior antispam@fricas.org (Waldek Hebisch) - 2026-01-14 03:57 +0000
              Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-14 10:47 +0200
              Re: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-14 14:49 +0000
          Re: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-10 17:08 +0000
        Re: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:48 -0800
          Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-11 22:52 +0200
            Re: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 22:53 -0800
              Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 11:44 +0200
                Re: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-12 20:29 -0500
            Re: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:29 -0800
    Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-09 15:54 +0200
      Re: On Undefined Behavior wij <wyniijj5@gmail.com> - 2026-01-10 00:08 +0800
    UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 16:28 +0200
      Re: UB or not UB? was: On Undefined Behavior bart <bc@freeuk.com> - 2026-01-12 15:58 +0000
        Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 20:08 +0200
          Re: UB or not UB? was: On Undefined Behavior scott@slp53.sl.home (Scott Lurndal) - 2026-01-12 20:02 +0000
            Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-12 21:09 -0500
              Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-13 11:31 +0200
                Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:21 -0500
          Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:19 -0500
            Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-14 09:35 +0100
              Re: UB or not UB? was: On Undefined Behavior antispam@fricas.org (Waldek Hebisch) - 2026-01-14 17:23 +0000
                Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-14 12:53 -0800
              Re: UB or not UB? was: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-14 14:43 -0800
                Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-15 11:45 +0100
                  Re: UB or not UB? was: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-15 06:16 -0500
                  Re: UB or not UB? was: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-15 04:04 -0800
                    Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-15 13:56 +0100
                    Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:34 -0800
                  Re: UB or not UB? was: On Undefined Behavior scott@slp53.sl.home (Scott Lurndal) - 2026-01-15 15:10 +0000
                    Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-15 16:23 +0100
        Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-13 21:54 +0000
          Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 21:58 -0500
            Re: UB or not UB? was: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-13 22:02 -0800
              Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-14 14:24 +0000
                Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-14 16:48 +0200
      Re: UB or not UB? was: On Undefined Behavior Andrey Tarasevich <noone@noone.net> - 2026-01-12 08:03 -0800
        Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 19:36 +0200
          Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-12 12:03 -0800
            Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 22:41 +0200
              Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-13 09:12 +0100
              Re: UB or not UB? was: On Undefined Behavior pa@see.signature.invalid (Pierre Asselin) - 2026-01-13 20:19 +0000
              Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:20 -0500
              Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 21:53 -0800
            Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-13 23:53 +0000
              Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-14 08:06 +0000
          Re: UB or not UB? was: On Undefined Behavior Andrey Tarasevich <noone@noone.net> - 2026-01-13 08:11 -0800
            Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:10 -0500
            Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 22:53 -0800
          Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:20 -0500
      Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-12 20:35 -0500
        Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-13 11:07 +0200
    Re: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-13 20:37 +0000

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#396409

Kaz Kylheku <046-301-5902@kylheku.com> wrote:
> On 2026-01-10, Michael S <already5chosen@yahoo.com> wrote:
>> On Fri, 9 Jan 2026 20:14:04 -0000 (UTC)
>> Kaz Kylheku <046-301-5902@kylheku.com> wrote:
>>
>>> On 2026-01-09, Michael S <already5chosen@yahoo.com> wrote:
>>> > On Fri, 09 Jan 2026 01:42:53 -0800
>>> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> >  
>>> >> 
>>> >> The important thing to realize is that the fundamental issue here
>>> >> is not a technical question but a social question.  In effect what
>>> >> you are asking is "why doesn't gcc (or clang, or whatever) do what
>>> >> I want or expect?".  The answer is different people want or expect
>>> >> different things.  For some people the behavior described is
>>> >> egregiously wrong and must be corrected immediately.  For other
>>> >> people the compiler is acting just as they think it should,
>>> >> nothing to see here, just fix the code and move on to the next
>>> >> bug.  Different people have different priorities.
>>> >>  
>>> >
>>> > I have hard time imagining sort of people that would have
>>> > objections in case compiler generates the same code as today, but
>>> > issues diagnostic.  
>>> 
>>> If false positives occur for the diagnostic frequently, there
>>> will be legitimate complaint.
>>> 
>>> If there is only a simple switch for it, it will get turned off
>>> and then it no longer serves its purpose of catching errors.
>>> 
>>> There are all kinds of optimizations compilers commonly do that could
>>> also be erroneous situations. For instance, eliminating dead code.
>>> 
>>
>><snip>
>>
>> I am not talking about  some general abstraction, but about specific
>> case.
>> You example is irrelevant.
>> -Warray-bounds exists for a long time. 
>> -Warray-bounds=1 is a part of -Wall set.
> 
> In your particular example, it is crystal clear that the "return 0"
> statement is elided away due to being considered unreachable, and the
> only reason for that can be undefined behavior, and the only undefined
> behavior is accessing the array out of bounds.
> 
> The compiler has decided to use the undefined behavior of the OOB array
> access as an unreachable() assertion, and at the same time neglected to
> issue the -Warray-bounds diagnostic which is expected to be issued for
> OOB access situations that the compiler can identify.
> 
> No one can claim that the OOB situation in the code has escaped
> identification, because a code-eliminating optimization was predicated
> on it.
> 
> It looks as if the logic for identifying OOB accesses for diagnosis is
> out of sync with the logic for identifying OOB accesses as assertions of
> undefined behavior.

AFAIK gcc warning machinery depends on information gathered during
optimization.  In this case reasonable guess is that optimizer
deleted offending access before warning machinery could see it.
I do not know how hard is to fix this.

-- 
                              Waldek Hebisch

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

#396414

On Tue, 13 Jan 2026 23:31:26 -0000 (UTC)
Kaz Kylheku <046-301-5902@kylheku.com> wrote:

> On 2026-01-10, Michael S <already5chosen@yahoo.com> wrote:
> > On Fri, 9 Jan 2026 20:14:04 -0000 (UTC)
> > Kaz Kylheku <046-301-5902@kylheku.com> wrote:
> >  
> >> On 2026-01-09, Michael S <already5chosen@yahoo.com> wrote:  
> >> > On Fri, 09 Jan 2026 01:42:53 -0800
> >> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >> >    
> >> >> 
> >> >> The important thing to realize is that the fundamental issue
> >> >> here is not a technical question but a social question.  In
> >> >> effect what you are asking is "why doesn't gcc (or clang, or
> >> >> whatever) do what I want or expect?".  The answer is different
> >> >> people want or expect different things.  For some people the
> >> >> behavior described is egregiously wrong and must be corrected
> >> >> immediately.  For other people the compiler is acting just as
> >> >> they think it should, nothing to see here, just fix the code
> >> >> and move on to the next bug.  Different people have different
> >> >> priorities. 
> >> >
> >> > I have hard time imagining sort of people that would have
> >> > objections in case compiler generates the same code as today, but
> >> > issues diagnostic.    
> >> 
> >> If false positives occur for the diagnostic frequently, there
> >> will be legitimate complaint.
> >> 
> >> If there is only a simple switch for it, it will get turned off
> >> and then it no longer serves its purpose of catching errors.
> >> 
> >> There are all kinds of optimizations compilers commonly do that
> >> could also be erroneous situations. For instance, eliminating dead
> >> code. 
> >
> ><snip>
> >
> > I am not talking about  some general abstraction, but about specific
> > case.
> > You example is irrelevant.
> > -Warray-bounds exists for a long time. 
> > -Warray-bounds=1 is a part of -Wall set.  
> 
> In your particular example, it is crystal clear that the "return 0"
> statement is elided away due to being considered unreachable, and the
> only reason for that can be undefined behavior, and the only undefined
> behavior is accessing the array out of bounds.
> 
> The compiler has decided to use the undefined behavior of the OOB
> array access as an unreachable() assertion, and at the same time
> neglected to issue the -Warray-bounds diagnostic which is expected to
> be issued for OOB access situations that the compiler can identify.
> 
> No one can claim that the OOB situation in the code has escaped
> identification, because a code-eliminating optimization was predicated
> on it.
> 
> It looks as if the logic for identifying OOB accesses for diagnosis is
> out of sync with the logic for identifying OOB accesses as assertions
> of undefined behavior.
> 
> In some situations, a surprising optimization occurs not because of
> undefined behavior, but because the compiler is assuming well-defined
> behavior (absence of UB).
> 
> That's not the case here; it is relying on the presence of UB. 
> 
> Or rather, it is relyiing on the absence of UB in an assinine way:
> it is assuming that the program does not reach the out-of-bounds
> access, because the sought-after value is found in the array.
> 
> But that reasoning requires awareness of the existence of the
> out-of-bounds access.
> 
> That's the crux of the issue there.
> 
> There is an unreachable() assertion in modern C. And it works by
> invoking undefined behavior; it means "let's have undefined behavior
> in this spot of the code".  And then, since the compiler assumes
> behavior is well-defined, assumes that that statement is not reached,
> nor anything after it, and can eliminate it.
> 
> The problem is that an OOB array access should not be treated
> as the same thing, as if it were unreachable(). Or, rather, no,
> sure it's okay to treat an OOB arrary access as unreachable() --- IF
> you generate the diagonstic about OOB array access that you
> were asked to generate!!!
> 

Would you be so kind to submit a bug report to gcc bugzilla?
In theory, I can do it myself, but I have a tendency to be lazy.

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

#396419

On 13/01/2026 23:31, Kaz Kylheku wrote:
> No one can claim that the OOB situation in the code has escaped
> identification, because a code-eliminating optimization was predicated
> on it.

One can. "Identification" means that inference or definition happened of
a proposition that two are the same. Here, merely behaviour was affected
consistent with some of the consequences of identification, which is weaker.


-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

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

#396334

On 09/01/2026 20:14, Kaz Kylheku wrote:
> If there is only a simple switch for it, it will get turned off
> and then it no longer serves its purpose of catching errors.


But it might still serve its purpose for assigning criminal liability.


-- 
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

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

#396347

Michael S <already5chosen@yahoo.com> writes:

> On Fri, 09 Jan 2026 01:42:53 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> highcrew <high.crew3868@fastmail.com> writes:
>>
>>> Hello,
>>>
>>> While I consider myself reasonably good as C programmer, I still
>>> have difficulties in understanding undefined behavior.
>>> I wonder if anyone in this NG could help me.
>>>
>>> Let's take an example.  There's plenty here:
>>> https://en.cppreference.com/w/c/language/behavior.html
>>> So let's focus on https://godbolt.org/z/48bn19Tsb
>>>
>>> For the lazy, I report it here:
>>>
>>>   int table[4] = {0};
>>>   int exists_in_table(int v)
>>>   {
>>>       // return true in one of the first 4 iterations
>>>       // or UB due to out-of-bounds access
>>>       for (int i = 0; i <= 4; i++) {
>>>           if (table[i] == v) return 1;
>>>       }
>>>       return 0;
>>>   }
>>>
>>> This is compiled (with no warning whatsoever) into:
>>>
>>>   exists_in_table:
>>>           mov     eax, 1
>>>           ret
>>>   table:
>>>           .zero   16
>>>
>>>
>>> Well, this is *obviously* wrong.  And sure, so is the original code,
>>> but I find it hard to think that the compiler isn't able to notice
>>> it, given that it is even "exploiting" it to produce very efficient
>>> code.
>>>
>>> I understand the formalism:  the resulting assembly is formally
>>> "correct", in that UB implies that anything can happen.
>>> Yet I can't think of any situation where the resulting assembly
>>> could be considered sensible.  The compiled function will
>>> basically return 1 for any input, and the final program will be
>>> buggy.
>>>
>>> Wouldn't it be more sensible to have a compilation error, or
>>> at least a warning?  The compiler will be happy even with -Wall
>>> -Wextra -Werror.
>>>
>>> There's plenty of documentation, articles and presentations that
>>> explain how this can make very efficient code... but nothing
>>> will answer this question:  do I really want to be efficiently
>>> wrong?
>>>
>>> I mean, yes I would find the problem, thanks to my 100% coverage
>>> unit testing, but couldn't the compiler give me a hint?
>>>
>>> Could someone drive me into this reasoning?  I know there is a lot
>>> of thinking behind it, yet everything seems to me very incorrect!
>>> I'm in deep cognitive dissonance here! :)  Help!
>>
>> The important thing to realize is that the fundamental issue here
>> is not a technical question but a social question.  In effect what
>> you are asking is "why doesn't gcc (or clang, or whatever) do what
>> I want or expect?".  The answer is different people want or expect
>> different things.  For some people the behavior described is
>> egregiously wrong and must be corrected immediately.  For other
>> people the compiler is acting just as they think it should,
>> nothing to see here, just fix the code and move on to the next
>> bug.  Different people have different priorities.
>
> I have hard time imagining sort of people that would have objections
> in case compiler generates the same code as today, but issues
> diagnostic.

It depends on what the tradeoffs are.  For example, given a
choice, I would rather have an option to prevent this particular
death-by-UB optimization than an option to issue a diagnostic.
Having both costs more effort than having just only one.

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

#396351

On Sun, 11 Jan 2026 11:48:08 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On Fri, 09 Jan 2026 01:42:53 -0800
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >  
> >> highcrew <high.crew3868@fastmail.com> writes:
> >>  
> >>> Hello,
> >>>
> >>> While I consider myself reasonably good as C programmer, I still
> >>> have difficulties in understanding undefined behavior.
> >>> I wonder if anyone in this NG could help me.
> >>>
> >>> Let's take an example.  There's plenty here:
> >>> https://en.cppreference.com/w/c/language/behavior.html
> >>> So let's focus on https://godbolt.org/z/48bn19Tsb
> >>>
> >>> For the lazy, I report it here:
> >>>
> >>>   int table[4] = {0};
> >>>   int exists_in_table(int v)
> >>>   {
> >>>       // return true in one of the first 4 iterations
> >>>       // or UB due to out-of-bounds access
> >>>       for (int i = 0; i <= 4; i++) {
> >>>           if (table[i] == v) return 1;
> >>>       }
> >>>       return 0;
> >>>   }
> >>>
> >>> This is compiled (with no warning whatsoever) into:
> >>>
> >>>   exists_in_table:
> >>>           mov     eax, 1
> >>>           ret
> >>>   table:
> >>>           .zero   16
> >>>
> >>>
> >>> Well, this is *obviously* wrong.  And sure, so is the original
> >>> code, but I find it hard to think that the compiler isn't able to
> >>> notice it, given that it is even "exploiting" it to produce very
> >>> efficient code.
> >>>
> >>> I understand the formalism:  the resulting assembly is formally
> >>> "correct", in that UB implies that anything can happen.
> >>> Yet I can't think of any situation where the resulting assembly
> >>> could be considered sensible.  The compiled function will
> >>> basically return 1 for any input, and the final program will be
> >>> buggy.
> >>>
> >>> Wouldn't it be more sensible to have a compilation error, or
> >>> at least a warning?  The compiler will be happy even with -Wall
> >>> -Wextra -Werror.
> >>>
> >>> There's plenty of documentation, articles and presentations that
> >>> explain how this can make very efficient code... but nothing
> >>> will answer this question:  do I really want to be efficiently
> >>> wrong?
> >>>
> >>> I mean, yes I would find the problem, thanks to my 100% coverage
> >>> unit testing, but couldn't the compiler give me a hint?
> >>>
> >>> Could someone drive me into this reasoning?  I know there is a lot
> >>> of thinking behind it, yet everything seems to me very incorrect!
> >>> I'm in deep cognitive dissonance here! :)  Help!  
> >>
> >> The important thing to realize is that the fundamental issue here
> >> is not a technical question but a social question.  In effect what
> >> you are asking is "why doesn't gcc (or clang, or whatever) do what
> >> I want or expect?".  The answer is different people want or expect
> >> different things.  For some people the behavior described is
> >> egregiously wrong and must be corrected immediately.  For other
> >> people the compiler is acting just as they think it should,
> >> nothing to see here, just fix the code and move on to the next
> >> bug.  Different people have different priorities.  
> >
> > I have hard time imagining sort of people that would have objections
> > in case compiler generates the same code as today, but issues
> > diagnostic.  
> 
> It depends on what the tradeoffs are.  For example, given a
> choice, I would rather have an option to prevent this particular
> death-by-UB optimization than an option to issue a diagnostic.
> Having both costs more effort than having just only one.

Me too.
But there are limits to what considered negotiable by worshippers of
nasal demons and what is beyond that. Warning is negotiable, turning
off the transformation is most likely beyond.

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

#396359

Michael S <already5chosen@yahoo.com> writes:
[...]
> But there are limits to what considered negotiable by worshippers of
> nasal demons and what is beyond that. Warning is negotiable, turning
> off the transformation is most likely beyond.

Your use of the word "worshippers" suggests a misunderstanding on
your part.

I certainly do not "worship" anything about C.  I don't think
anyone else you've been talking to does either.  I have a pretty
good understanding of it.  There are plenty of things I don't
particularly like.

In the vast majority of my posts here, I simply try to explain what
the standard actually says and offer advice based on that.

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

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

#396369

On Sun, 11 Jan 2026 22:53:53 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> [...]
> > But there are limits to what considered negotiable by worshippers of
> > nasal demons and what is beyond that. Warning is negotiable, turning
> > off the transformation is most likely beyond.  
> 
> Your use of the word "worshippers" suggests a misunderstanding on
> your part.
> 
> I certainly do not "worship" anything about C.  I don't think
> anyone else you've been talking to does either.  I have a pretty
> good understanding of it.  There are plenty of things I don't
> particularly like.
> 
> In the vast majority of my posts here, I simply try to explain what
> the standard actually says and offer advice based on that.
> 

About my personal vocabulary.

Normally phrase "worshippers of nasal demons" in my posts refers to
faction among developers and maintainers of gcc and clang compilers. I
think that it's not an unusual use of the phrase, but I can be wrong
about it.

AFAIK, you are not gcc or clang maintainer. So, not a "worshipper".
When I want to characterize [in derogatory fashion] people that have no
direct influence on behavior of common software tools, but share the
attitude of "worshippers" toward UBs then I use phrase 'language
lawyers'.

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

#396382

On 2026-01-12 04:44, Michael S wrote:
...
> Normally phrase "worshippers of nasal demons" in my posts refers to
> faction among developers and maintainers of gcc and clang compilers. I
> think that it's not an unusual use of the phrase, but I can be wrong
> about it.

Which faction would that be? I'm sure there's more than one to choose 
from. An example of what they've done that, in your opinion, justifies 
that description might also be helpful

...
> AFAIK, you are not gcc or clang maintainer. So, not a "worshipper".
> When I want to characterize [in derogatory fashion] people that have no
> direct influence on behavior of common software tools, but share the
> attitude of "worshippers" toward UBs then I use phrase 'language
> lawyers'."language lawyers", at least, I understand, having frequently been 
described as one myself. It means those who are knowledgeable about what 
the standard allows and prohibits, both for programs and for 
implementations. I'm no sure why you'd consider them "worshippers" of 
UB; they are characterized as language lawyers because they know 
precisely when the behavior is or is not UB - but that says nothing 
about whether they approve of UB or not. They would still be language 
lawyers whether they approved of UB, or despised it.

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

#396571

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 11 Jan 2026 11:48:08 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Fri, 09 Jan 2026 01:42:53 -0800
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> highcrew <high.crew3868@fastmail.com> writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> While I consider myself reasonably good as C programmer, I still
>>>>> have difficulties in understanding undefined behavior.
>>>>> I wonder if anyone in this NG could help me.
>>>>>
>>>>> Let's take an example.  There's plenty here:
>>>>> https://en.cppreference.com/w/c/language/behavior.html
>>>>> So let's focus on https://godbolt.org/z/48bn19Tsb
>>>>>
>>>>> For the lazy, I report it here:
>>>>>
>>>>>   int table[4] = {0};
>>>>>   int exists_in_table(int v)
>>>>>   {
>>>>>       // return true in one of the first 4 iterations
>>>>>       // or UB due to out-of-bounds access
>>>>>       for (int i = 0; i <= 4; i++) {
>>>>>           if (table[i] == v) return 1;
>>>>>       }
>>>>>       return 0;
>>>>>   }
>>>>>
>>>>> This is compiled (with no warning whatsoever) into:
>>>>>
>>>>>   exists_in_table:
>>>>>           mov     eax, 1
>>>>>           ret
>>>>>   table:
>>>>>           .zero   16
>>>>>
>>>>>
>>>>> Well, this is *obviously* wrong.  And sure, so is the original
>>>>> code, but I find it hard to think that the compiler isn't able to
>>>>> notice it, given that it is even "exploiting" it to produce very
>>>>> efficient code.
>>>>>
>>>>> I understand the formalism:  the resulting assembly is formally
>>>>> "correct", in that UB implies that anything can happen.
>>>>> Yet I can't think of any situation where the resulting assembly
>>>>> could be considered sensible.  The compiled function will
>>>>> basically return 1 for any input, and the final program will be
>>>>> buggy.
>>>>>
>>>>> Wouldn't it be more sensible to have a compilation error, or
>>>>> at least a warning?  The compiler will be happy even with -Wall
>>>>> -Wextra -Werror.
>>>>>
>>>>> There's plenty of documentation, articles and presentations that
>>>>> explain how this can make very efficient code... but nothing
>>>>> will answer this question:  do I really want to be efficiently
>>>>> wrong?
>>>>>
>>>>> I mean, yes I would find the problem, thanks to my 100% coverage
>>>>> unit testing, but couldn't the compiler give me a hint?
>>>>>
>>>>> Could someone drive me into this reasoning?  I know there is a lot
>>>>> of thinking behind it, yet everything seems to me very incorrect!
>>>>> I'm in deep cognitive dissonance here! :)  Help!
>>>>
>>>> The important thing to realize is that the fundamental issue here
>>>> is not a technical question but a social question.  In effect what
>>>> you are asking is "why doesn't gcc (or clang, or whatever) do what
>>>> I want or expect?".  The answer is different people want or expect
>>>> different things.  For some people the behavior described is
>>>> egregiously wrong and must be corrected immediately.  For other
>>>> people the compiler is acting just as they think it should,
>>>> nothing to see here, just fix the code and move on to the next
>>>> bug.  Different people have different priorities.
>>>
>>> I have hard time imagining sort of people that would have objections
>>> in case compiler generates the same code as today, but issues
>>> diagnostic.
>>
>> It depends on what the tradeoffs are.  For example, given a
>> choice, I would rather have an option to prevent this particular
>> death-by-UB optimization than an option to issue a diagnostic.
>> Having both costs more effort than having just only one.
>
> Me too.
> But there are limits to what considered negotiable by worshippers of
> nasal demons and what is beyond that.  Warning is negotiable, turning
> off the transformation is most likely beyond.

What other people think on that matter doesn't change
my comment.

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

#396322

On Thu, 1 Jan 2026 22:54:05 +0100
highcrew <high.crew3868@fastmail.com> wrote:

> Hello,
> 
> While I consider myself reasonably good as C programmer, I still
> have difficulties in understanding undefined behavior.
> I wonder if anyone in this NG could help me.
> 
> Let's take an example.  There's plenty here:
> https://en.cppreference.com/w/c/language/behavior.html
> So let's focus on https://godbolt.org/z/48bn19Tsb
> 
> For the lazy, I report it here:
> 
>    int table[4] = {0};
>    int exists_in_table(int v)
>    {
>        // return true in one of the first 4 iterations
>        // or UB due to out-of-bounds access
>        for (int i = 0; i <= 4; i++) {
>            if (table[i] == v) return 1;
>        }
>        return 0;
>    }
> 
> This is compiled (with no warning whatsoever) into:
> 
>    exists_in_table:
>            mov     eax, 1
>            ret
>    table:
>            .zero   16
> 
> 
> Well, this is *obviously* wrong. And sure, so is the original code,
> but I find it hard to think that the compiler isn't able to notice it,
> given that it is even "exploiting" it to produce very efficient code.
> 
> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
> Yet I can't think of any situation where the resulting assembly
> could be considered sensible.  The compiled function will
> basically return 1 for any input, and the final program will be
> buggy.
> 
> Wouldn't it be more sensible to have a compilation error, or
> at least a warning?  The compiler will be happy even with -Wall
> -Wextra -Werror.
> 
> There's plenty of documentation, articles and presentations that
> explain how this can make very efficient code... but nothing
> will answer this question: do I really want to be efficiently
> wrong?
> 
> I mean, yes I would find the problem, thanks to my 100% coverage
> unit testing, but couldn't the compiler give me a hint?
> 
> Could someone drive me into this reasoning? I know there is a lot of
> thinking behind it, yet everything seems to me very incorrect!
> I'm in deep cognitive dissonance here! :) Help!
> 

Personally, I am not shocked by gcc behavior in this case. May be,
saddened, but not shocked.
I am shocked by slightly modified variant of it.

struct {
  int table[4];
  int other_table[4];
} bar;

int exists_in_table(int v)
{
   for (int i = 0; i <= 4; i++) {
     if (bar.table[i] == v) 
       return 1;
   }
   return 0;
}

An original variant is unlikely to be present in the code bases that I
care about professionally. But something akin to modified variant could
be present.
Godbolt shows that this behaviour was first introduced in gcc5. It was
backported to gcc4 series in gcc 4.8

One of my suspect code bases currently at gcc 4.7. I was considering
moving to 5.3. In lights of that example, I likely am not going to
do it.
Unless there is a magic flag that disables this optimization.

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

#396323

On Fri, 2026-01-09 at 15:54 +0200, Michael S wrote:
> On Thu, 1 Jan 2026 22:54:05 +0100
> highcrew <high.crew3868@fastmail.com> wrote:
> 
> > Hello,
> > 
> > While I consider myself reasonably good as C programmer, I still
> > have difficulties in understanding undefined behavior.
> > I wonder if anyone in this NG could help me.
> > 
> > Let's take an example.  There's plenty here:
> > https://en.cppreference.com/w/c/language/behavior.html
> > So let's focus on https://godbolt.org/z/48bn19Tsb
> > 
> > For the lazy, I report it here:
> > 
> >    int table[4] = {0};
> >    int exists_in_table(int v)
> >    {
> >        // return true in one of the first 4 iterations
> >        // or UB due to out-of-bounds access
> >        for (int i = 0; i <= 4; i++) {
> >            if (table[i] == v) return 1;
> >        }
> >        return 0;
> >    }
> > 
> > This is compiled (with no warning whatsoever) into:
> > 
> >    exists_in_table:
> >            mov     eax, 1
> >            ret
> >    table:
> >            .zero   16
> > 
> > 
> > Well, this is *obviously* wrong. And sure, so is the original code,
> > but I find it hard to think that the compiler isn't able to notice it,
> > given that it is even "exploiting" it to produce very efficient code.
> > 
> > I understand the formalism: the resulting assembly is formally
> > "correct", in that UB implies that anything can happen.
> > Yet I can't think of any situation where the resulting assembly
> > could be considered sensible.  The compiled function will
> > basically return 1 for any input, and the final program will be
> > buggy.

It is UB, what the implement is irrevant.

The for loop above is equivalent to:

 for (int i = 0; i <= 3; i++) {
           if (table[i] == v) return 1;
       }
 if(table[i]==v) {  // implement defined
   return 1;
 }
 // implement defined

So, always returning 1 is correct compilation (no way exists_in_table(v) will return non-1).

> > Wouldn't it be more sensible to have a compilation error, or
> > at least a warning?  The compiler will be happy even with -Wall
> > -Wextra -Werror.
> > 
> > There's plenty of documentation, articles and presentations that
> > explain how this can make very efficient code... but nothing
> > will answer this question: do I really want to be efficiently
> > wrong?
> > 
> > I mean, yes I would find the problem, thanks to my 100% coverage
> > unit testing, but couldn't the compiler give me a hint?
> > 
> > Could someone drive me into this reasoning? I know there is a lot of
> > thinking behind it, yet everything seems to me very incorrect!
> > I'm in deep cognitive dissonance here! :) Help!
> > 
> 
> Personally, I am not shocked by gcc behavior in this case. May be,
> saddened, but not shocked.
> I am shocked by slightly modified variant of it.
> 
> struct {
>   int table[4];
>   int other_table[4];
> } bar;
> 
> int exists_in_table(int v)
> {
>    for (int i = 0; i <= 4; i++) {
>      if (bar.table[i] == v) 
>        return 1;
>    }
>    return 0;
> }
> 
> An original variant is unlikely to be present in the code bases that I
> care about professionally. But something akin to modified variant could
> be present.
> Godbolt shows that this behaviour was first introduced in gcc5. It was
> backported to gcc4 series in gcc 4.8
> 
> One of my suspect code bases currently at gcc 4.7. I was considering
> moving to 5.3. In lights of that example, I likely am not going to
> do it.
> Unless there is a magic flag that disables this optimization.
> 

I am also shocked many seemingly missed.

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

#396372 — UB or not UB? was: On Undefined Behavior

On Thu, 1 Jan 2026 22:54:05 +0100
highcrew <high.crew3868@fastmail.com> wrote:

> Hello,
> 
> While I consider myself reasonably good as C programmer, I still
> have difficulties in understanding undefined behavior.
> I wonder if anyone in this NG could help me.
> 
> Let's take an example.  There's plenty here:
> https://en.cppreference.com/w/c/language/behavior.html
> So let's focus on https://godbolt.org/z/48bn19Tsb
> 
> For the lazy, I report it here:
> 
>    int table[4] = {0};
>    int exists_in_table(int v)
>    {
>        // return true in one of the first 4 iterations
>        // or UB due to out-of-bounds access
>        for (int i = 0; i <= 4; i++) {
>            if (table[i] == v) return 1;
>        }
>        return 0;
>    }
> 
> This is compiled (with no warning whatsoever) into:
> 
>    exists_in_table:
>            mov     eax, 1
>            ret
>    table:
>            .zero   16
> 
> 
> Well, this is *obviously* wrong. And sure, so is the original code,
> but I find it hard to think that the compiler isn't able to notice it,
> given that it is even "exploiting" it to produce very efficient code.
> 
> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
> Yet I can't think of any situation where the resulting assembly
> could be considered sensible.  The compiled function will
> basically return 1 for any input, and the final program will be
> buggy.
> 
> Wouldn't it be more sensible to have a compilation error, or
> at least a warning?  The compiler will be happy even with -Wall
> -Wextra -Werror.
> 
> There's plenty of documentation, articles and presentations that
> explain how this can make very efficient code... but nothing
> will answer this question: do I really want to be efficiently
> wrong?
> 
> I mean, yes I would find the problem, thanks to my 100% coverage
> unit testing, but couldn't the compiler give me a hint?
> 
> Could someone drive me into this reasoning? I know there is a lot of
> thinking behind it, yet everything seems to me very incorrect!
> I'm in deep cognitive dissonance here! :) Help!
> 

On related note.


struct bar1 {
  int table[4];
  int other_table[4];
};

struct bar2 {
  int other_table[4];
  int table[4];
};

int foo1(struct bar1* p, int v)
{
  for (int i = 0; i <= 4; ++i)
    if (p->table[i] == v)
      return 1;
  return 0;
}


int foo2(struct bar2* p, int v)
{
  for (int i = 0; i <= 4; ++i)
    if (p->table[i] == v)
      return 1;
  return 0;
}

According to C Standard, access to p->table[4] in foo1() is UB.
[O.T.]
I want to use language (or, better, standardize dialect of C) in which
behavior in this case is defined, but I am bad at influencing other
people. So can not get what I want.
[/O.T.]

Now the question.
What The Standard says about foo2() ? Is there UB in foo2() as well?
gcc code generator does not think so.

	.file	"ub.c"
	.text
	.p2align 4
	.globl	foo1
	.def	foo1;	.scl	2;	.type
	32;	.endef .seh_proc	foo1
foo1:
	.seh_endprologue
	movl	$1, %eax
	ret
	.seh_endproc
	.p2align 4
	.globl	foo2
	.def	foo2;	.scl	2;	.type
	32;	.endef .seh_proc	foo2
foo2:
	.seh_endprologue
	leaq	16(%rcx), %rax
	addq	$36, %rcx
.L5:
	cmpl	%edx, (%rax)
	je	.L6
	addq	$4, %rax
	cmpq	%rcx, %rax
	jne	.L5
	xorl	%eax, %eax
	ret
	.p2align 4,,10
	.p2align 3
.L6:
	movl	$1, %eax
	ret
	.seh_endproc
	.ident	"GCC: (Rev8, Built by MSYS2 project) 15.2.0"

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

#396373 — Re: UB or not UB? was: On Undefined Behavior

On 12/01/2026 14:28, Michael S wrote:
> On Thu, 1 Jan 2026 22:54:05 +0100

> On related note.
> 
> 
> struct bar1 {
>    int table[4];
>    int other_table[4];
> };
> 
> struct bar2 {
>    int other_table[4];
>    int table[4];
> };
> 
> int foo1(struct bar1* p, int v)
> {
>    for (int i = 0; i <= 4; ++i)
>      if (p->table[i] == v)
>        return 1;
>    return 0;
> }
> 
> 
> int foo2(struct bar2* p, int v)
> {
>    for (int i = 0; i <= 4; ++i)
>      if (p->table[i] == v)
>        return 1;
>    return 0;
> }
> 
> According to C Standard, access to p->table[4] in foo1() is UB.
> [O.T.]
> I want to use language (or, better, standardize dialect of C) in which
> behavior in this case is defined, but I am bad at influencing other
> people. So can not get what I want.
> [/O.T.]


So you want to deliberately read one element past the end because you 
know it will be the first element of other_table?

I think then it would be better writing it like this:

  struct bar1 {
    union {
      struct {
        int table[4];
        int other_table[4];
       };
      int xtable[8];
    };
  };

  int foo1(struct bar1* p, int v)
  {
    for (int i = 0; i <= 4; ++i)
      if (p->xtable[i] == v)
        return 1;
    return 0;
  }

At least your intent is signaled to whomever is reading your code.

But I don't know if UB goes away, if you intend writing to .table and 
.other_table, and reading those values via .xtable (I can't remember the 
rules).

I'm not even sure about there being no padding between .table and 
.other_table.

(In my systems language, the behaviour of your original foo1, in an 
equivalent program, is well-defined. But not of foo2, given that you may 
read some garbage value beyond the struct, which may or may not be 
within valid memory.)


> Now the question.
> What The Standard says about foo2() ? Is there UB in foo2() as well?

Given that you may be reading garbage as I said, whether it is UB or not 
is irrelevant; your program has a bug.

Unless you can add extra context which would make that reasonable. For 
example, the struct is within an array, it's not the last element, so it 
will read the first element of .other_table, and you are doing this 
knowingly rather than through oversight.

It might well be UB, but that is a separate problem.

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

#396377 — Re: UB or not UB? was: On Undefined Behavior

On Mon, 12 Jan 2026 15:58:15 +0000
bart <bc@freeuk.com> wrote:

> On 12/01/2026 14:28, Michael S wrote:
> > On Thu, 1 Jan 2026 22:54:05 +0100  
> 
> > On related note.
> > 
> > 
> > struct bar1 {
> >    int table[4];
> >    int other_table[4];
> > };
> > 
> > struct bar2 {
> >    int other_table[4];
> >    int table[4];
> > };
> > 
> > int foo1(struct bar1* p, int v)
> > {
> >    for (int i = 0; i <= 4; ++i)
> >      if (p->table[i] == v)
> >        return 1;
> >    return 0;
> > }
> > 
> > 
> > int foo2(struct bar2* p, int v)
> > {
> >    for (int i = 0; i <= 4; ++i)
> >      if (p->table[i] == v)
> >        return 1;
> >    return 0;
> > }
> > 
> > According to C Standard, access to p->table[4] in foo1() is UB.
> > [O.T.]
> > I want to use language (or, better, standardize dialect of C) in
> > which behavior in this case is defined, but I am bad at influencing
> > other people. So can not get what I want.
> > [/O.T.]  
> 
> 
> So you want to deliberately read one element past the end because you 
> know it will be the first element of other_table?
> 

Yes. I primarily want it for multi-dimensional arrays. Making the same
pattern defined in 'struct' is less important in practice, but desirable
for consistency between arrays and structures.

> I think then it would be better writing it like this:
> 
>   struct bar1 {
>     union {
>       struct {
>         int table[4];
>         int other_table[4];
>        };
>       int xtable[8];
>     };
>   };
> 
>   int foo1(struct bar1* p, int v)
>   {
>     for (int i = 0; i <= 4; ++i)
>       if (p->xtable[i] == v)
>         return 1;
>     return 0;
>   }
> 
> At least your intent is signaled to whomever is reading your code.
>

If were use language or dialect in which the behavior is defined, why
would you consider the second variant better?
I don't mean in this particular very simplified example, but generally,
where layout is more complicated.

> But I don't know if UB goes away, if you intend writing to .table and 
> .other_table, and reading those values via .xtable (I can't remember
> the rules).
> 
> I'm not even sure about there being no padding between .table and 
> .other_table.

Considering that they both 'int' I don't think that it could happen,
even in standard C. In "my" dialect, padding in such situation can be
explicitly disallowed by the standard.

> 
> (In my systems language, the behaviour of your original foo1, in an 
> equivalent program, is well-defined. But not of foo2, given that you
> may read some garbage value beyond the struct, which may or may not
> be within valid memory.)
> 
> 
> > Now the question.
> > What The Standard says about foo2() ? Is there UB in foo2() as
> > well?  
> 
> Given that you may be reading garbage as I said, whether it is UB or
> not is irrelevant; your program has a bug.

Whether there is bug or not depends on what caller passed to foo2().
There are great many programs around that do similar things and contain
no bugs. Most typically, caller creates argument p by casting of char
array that is long enough for table member to hold more than 4
elements.
Without seeing code on the caller's site we could only guess, due to
suspect way the code is written, that there is bug. But we can't be
sure.

> 
> Unless you can add extra context which would make that reasonable.
> For example, the struct is within an array, it's not the last
> element, so it will read the first element of .other_table, and you
> are doing this knowingly rather than through oversight.
> 
> It might well be UB, but that is a separate problem.
> 
> 

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

#396378 — Re: UB or not UB? was: On Undefined Behavior

Michael S <already5chosen@yahoo.com> writes:
>On Mon, 12 Jan 2026 15:58:15 +0000
>bart <bc@freeuk.com> wrote:
>
>> On 12/01/2026 14:28, Michael S wrote:
>> > On Thu, 1 Jan 2026 22:54:05 +0100  
>> 
>> > On related note.
>> > 
>> > 
>> > struct bar1 {
>> >    int table[4];
>> >    int other_table[4];
>> > };
>> > 
>> > struct bar2 {
>> >    int other_table[4];
>> >    int table[4];
>> > };
>> > 
>> > int foo1(struct bar1* p, int v)
>> > {
>> >    for (int i = 0; i <= 4; ++i)
>> >      if (p->table[i] == v)
>> >        return 1;
>> >    return 0;
>> > }
>> > 
>> > 
>> > int foo2(struct bar2* p, int v)
>> > {
>> >    for (int i = 0; i <= 4; ++i)
>> >      if (p->table[i] == v)
>> >        return 1;
>> >    return 0;
>> > }
>> > 
>> > According to C Standard, access to p->table[4] in foo1() is UB.
>> > [O.T.]
>> > I want to use language (or, better, standardize dialect of C) in
>> > which behavior in this case is defined, but I am bad at influencing
>> > other people. So can not get what I want.
>> > [/O.T.]  
>> 
>> 
>> So you want to deliberately read one element past the end because you 
>> know it will be the first element of other_table?
>> 
>
>Yes. I primarily want it for multi-dimensional arrays. 

So declare it as int table[4][4].

$ cat /tmp/a.c
#include <stdio.h>
int table[4][4] = { {1,2,3,4}, {5,6,7,8}, {9, 10, 11, 12}, {13, 14, 15, 16} };

int main(int argc, const char **argv, const char **envp)
{

   printf("%u\n", table[3][2]);
   return 0;
}
$ cc -o /tmp/a /tmp/a.c
$ /tmp/a               
15

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

#396384 — Re: UB or not UB? was: On Undefined Behavior

On 2026-01-12 15:02, Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Mon, 12 Jan 2026 15:58:15 +0000
>> bart <bc@freeuk.com> wrote:
>>
>>> On 12/01/2026 14:28, Michael S wrote:
...
>>>> struct bar1 {
>>>>     int table[4];
>>>>     int other_table[4];
>>>> };
...
>>> So you want to deliberately read one element past the end because you
>>> know it will be the first element of other_table?
>>>
>>
>> Yes. I primarily want it for multi-dimensional arrays.
> 
> So declare it as int table[4][4].


Note that this suggestion does not make the behavior defined. It is 
undefined behavior to make dereference table[0]+4, and it is undefined 
behavior to make any use of table[0]+5.

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

#396389 — Re: UB or not UB? was: On Undefined Behavior

On Mon, 12 Jan 2026 21:09:25 -0500
"James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:

> On 2026-01-12 15:02, Scott Lurndal wrote:
> > Michael S <already5chosen@yahoo.com> writes:  
> >> On Mon, 12 Jan 2026 15:58:15 +0000
> >> bart <bc@freeuk.com> wrote:
> >>  
> >>> On 12/01/2026 14:28, Michael S wrote:  
> ...
> >>>> struct bar1 {
> >>>>     int table[4];
> >>>>     int other_table[4];
> >>>> };  
> ...
> >>> So you want to deliberately read one element past the end because
> >>> you know it will be the first element of other_table?
> >>>  
> >>
> >> Yes. I primarily want it for multi-dimensional arrays.  
> > 
> > So declare it as int table[4][4].  
> 
> 
> Note that this suggestion does not make the behavior defined. It is 
> undefined behavior to make dereference table[0]+4, and it is
> undefined behavior to make any use of table[0]+5.
> 

Pay attention that Scott didn't suggest that dereferencing table[0][4]
in his example is defined.
Not that I understood what he wanted to suggest :(

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

#396408 — Re: UB or not UB? was: On Undefined Behavior

On 2026-01-13 04:31, Michael S wrote:
> On Mon, 12 Jan 2026 21:09:25 -0500
> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 2026-01-12 15:02, Scott Lurndal wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>>> On Mon, 12 Jan 2026 15:58:15 +0000
>>>> bart <bc@freeuk.com> wrote:
>>>>> On 12/01/2026 14:28, Michael S wrote:
>> ...
>>>>>> struct bar1 {
>>>>>> int table[4];
>>>>>> int other_table[4];
>>>>>> };
>> ...
>>>>> So you want to deliberately read one element past the end because
>>>>> you know it will be the first element of other_table?
>>>>
>>>> Yes. I primarily want it for multi-dimensional arrays.
>>>
>>> So declare it as int table[4][4].
>>
>>
>> Note that this suggestion does not make the behavior defined. It is
>> undefined behavior to make dereference table[0]+4, and it is
>> undefined behavior to make any use of table[0]+5.
>>
>
> Pay attention that Scott didn't suggest that dereferencing table[0][4]
> in his example is defined.
> Not that I understood what he wanted to suggest :(
That's the difference - I did understand. In your struct, other_table is 
not required to immediately follow table, but in the 2D array, table[0] 
is guaranteed to follow table[1]. That's not sufficient to make 
table[0][5] have defined behavior, but many people are unaware of that, 
or are willing to take the chance.

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

#396405 — Re: UB or not UB? was: On Undefined Behavior

On 2026-01-12 13:08, Michael S wrote:
> On Mon, 12 Jan 2026 15:58:15 +0000
> bart <bc@freeuk.com> wrote:
...
>> struct bar1 {
>> union {
>> struct {
>> int table[4];
>> int other_table[4];
>> };
>> int xtable[8];
>> };
>> };
...
>> I'm not even sure about there being no padding between .table and
>> .other_table.
>
> Considering that they both 'int' I don't think that it could happen,
> even in standard C.

"Each non-bit-field member of a structure or union object is aligned in 
an implementation-defined manner appropriate to its type." (6.7.3.2p16)
"... There can be unnamed padding within a structure object, but not
at its beginning." (6.7.3.2p17)

While I can't think of any good reason for an implementation to insert 
padding between those objects, it would not violate any requirement of 
the standard if one did.

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

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

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

csiph-web