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 6 of 6 — ← Prev page 1 2 3 4 5 [6]

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

On 12/01/2026 21:41, Michael S wrote:
> On Mon, 12 Jan 2026 12:03:36 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> 
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 12 Jan 2026 08:03:31 -0800
>>> Andrey Tarasevich <noone@noone.net> wrote:
>>>   
>>>> On Mon 1/12/2026 6:28 AM, Michael S wrote:
>>>>   
>>>>> According to C Standard, access to p->table[4] in foo1() is UB.
>>>>> ...
>>>>> Now the question.
>>>>> What The Standard says about foo2() ? Is there UB in foo2() as
>>>>> well?
>>>>
>>>> Yes, in the same sense as in `foo1`.
>>>>   
>>>>> gcc code generator does not think so.
>>>>
>>>> It definitely does.
>>
>> Right.
>>
> 
> May be. But it's not expressed by gcc code generator or by any wranings.
> So, how can we know?
> 
>>> Do you have citation from the Standard?
>>
>> The short answer is section 6.5.6 paragraph 8.
>>
> 
> I am reading N3220 draft
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
> Here section 6.5.6 has no paragraph 8 :(
> 

The C standards managed to keep section numbers and even paragraph 
numbers consistent between versions for a long time, but there are a 
number of differences in C23.  6.5.6p8 in, for example, C11, is 6.5.7p9 
in N3220.  (N3220 is an early draft of the next Cy version, and is far 
from complete.  The best C23 draft is N3096, where the relevant 
paragraph is 6.5.6p9.)

>> There is amplification in Annex J.2, roughly three pages
>> after the start of J.2.  You can search for "an array
>> subscript is out of range", where there is a clarifying
>> example.
> 
> I see the following text:
> "An array subscript is out of range, even if an object is apparently
> accessible with the given subscript (as in the lvalue expression
> a[1][7] given the declaration int a[4][5]) (6.5.7)."
> 
> That's what you had in mind?
> 

I can't read Tim's mind, but it is certainly an example that /I/ think 
is pretty clear.  The list of undefined behaviours in J.2 is 
non-normative (meaning it does not define the rules of the language, it 
just tries to explain them or list them), and not complete (lots of 
things are UB without being listed, simply because the standard does not 
define behaviours for them).  But the list in J.2 can be a very useful 
summary of UB's, and it can be easier to follow than to understand the 
referenced sections in the normative text.

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

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

Michael S <already5chosen@yahoo.com> wrote:

> > There is amplification in Annex J.2, roughly three pages
> > after the start of J.2.  You can search for "an array
> > subscript is out of range", where there is a clarifying
> > example.

> I see the following text:
> "An array subscript is out of range, even if an object is apparently
> accessible with the given subscript (as in the lvalue expression
> a[1][7] given the declaration int a[4][5]) (6.5.7)."


In numerical analysis it is often useful to flatten
multidimensional arrays. For example,

    void initialize(int table[4][4])
    {
	int *flat= &table[0][0];
	for (int i= 0; i<16; i++) flat[i]= i;
    }

Accessing table[0][i] would have been UB according to appendix J.
Is going through flat[i] UB as well? Probably, and that's a shame.

-- 
pa at panix dot com

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

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

On 2026-01-12 15:41, Michael S wrote:
...
> May be. But it's not expressed by gcc code generator or by any wranings.
> So, how can we know?

It's impossible to determine whether the behavior of a piece of code is 
defined or undefined by examining the output of code generator, because 
there's nothing that a code generator is required to do when the 
behavior is undefined, that it's not allowed to do when the behavior is 
defined (and vice-versa). The only way to determine whether the behavior 
is defined is by examining the code and understanding what the relevant 
clauses of the standard say about it's behavior.

...
> I am reading N3220 draft
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
> Here section 6.5.6 has no paragraph 8 :(

The latest version is n3685, but the behavior is still undefined.

>> There is amplification in Annex J.2, roughly three pages
>> after the start of J.2. You can search for "an array
>> subscript is out of range", where there is a clarifying
>> example.
>
> I see the following text:
> "An array subscript is out of range, even if an object is apparently
> accessible with the given subscript (as in the lvalue expression
> a[1][7] given the declaration int a[4][5]) (6.5.7)."
>
> That's what you had in mind?

Yes, a[1][7] is defined by the standard as being equivalent to 
*(*(a+1)+7). The +7 produces the overflow referred to in 6.5.7p9, 
because 7 is greater than the 5 in "int a[4][5]", which makes it clear 
that it's the length of the sub-array that matters, the fact that 
there's another sub-array immediately following it does not render the 
behavior defined.

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

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

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 12 Jan 2026 12:03:36 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 12 Jan 2026 08:03:31 -0800
>>> Andrey Tarasevich <noone@noone.net> wrote:
>>>
>>>> On Mon 1/12/2026 6:28 AM, Michael S wrote:
>>>>
>>>>> According to C Standard, access to p->table[4] in foo1() is UB.
>>>>> ...
>>>>> Now the question.
>>>>> What The Standard says about foo2() ? Is there UB in foo2() as
>>>>> well?
>>>>
>>>> Yes, in the same sense as in `foo1`.
>>>>
>>>>> gcc code generator does not think so.
>>>>
>>>> It definitely does.
>>
>> Right.
>
> May be.  But it's not expressed by gcc code generator or by any
> wranings.  So, how can we know?

I know the behavior is undefined by what is said in the C standard.

For what gcc developers think of the question, for me the totality
of circumstantial evidence suffices.  I have nothing to offer if the
goal is to convince skeptics.

>>> Do you have citation from the Standard?
>>
>> The short answer is section 6.5.6 paragraph 8.
>
> I am reading N3220 draft
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
> Here section 6.5.6 has no paragraph 8 :(

I hope it isn't too much to expect that if N3220 doesn't have
what you are looking for then you would try looking in earlier
versions of the C standard, either C99 (N1256) or C11 (N1570).

>> There is amplification in Annex J.2, roughly three pages
>> after the start of J.2.  You can search for "an array
>> subscript is out of range", where there is a clarifying
>> example.
>
> I see the following text:
> "An array subscript is out of range, even if an object is apparently
> accessible with the given subscript (as in the lvalue expression
> a[1][7] given the declaration int a[4][5]) (6.5.7)."
>
> That's what you had in mind?

Yes.

Note the section quoted section number, 6.5.7, gives the correct
section number in N3220 to locate the aforementioned reference.
I see that in N3220 the relevant paragraph is paragraph 9 rather
than paragraph 8.  I hope that would be evident by looking at the
contents of section 6.5.7.

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

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

On 12/01/2026 20:03, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:

>> Do you have citation from the Standard?
> 
> The short answer is section 6.5.6 paragraph 8.
> 
> There is amplification in Annex J.2, roughly three pages after the 
> start of J.2.  You can search for "an array subscript is out of 
> range", where there is a clarifying example.


That is "... /apparently/ /accessible/ ..." not "... /actually/
/present/ ..." and "... given the /declaration/ ..." not "... given the
/definition/ ..."

Annex J.2 is not an amplification but an inference. Fortunately there is
logic involved so statements are logical sums and logical products, the
logical sum of 1 with 1 is 1 as is the logical product, not 2 so no
amplification. An inference in a technical defining document from its
own definitions is just clarification, not amplification, and a sanity
check that might help find inconsistencies.

From 6.5.7:

"8 For the purposes of these operators, a pointer to an object that is
not an element of an array behaves
the same as a pointer to the first element of an array of length one
with the type of the object as its
element type.
9 When an expression that has integer type is added to or subtracted
from a pointer, the result has the
type of the pointer operand. If the pointer operand points to an element
of an array object, and the
array is large enough ..."

Combining these, and padding requirements, you can definedly reach
existing elements of multidimensional array objects. The pointer to the
first element of the first nested array is as good as a pointer to the
first element of a non-nested array through which you can reach the
elements in the second nested array if they exist. That depends on the
/definition/ of the array object, not on the /declaration/, hence the
inference whose conclusion was stated in J.2 regarding the
ineffectiveness of /declarations/.

-- 
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]

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

On 13/01/2026 23:53, Tristan Wibberley wrote:
> Combining these, and padding requirements, you can definedly reach

I recall padding requirements for the extremes of array object types
from discussions on usenet years ago, however, perhaps they were for C++
because I can find nonsuch, nonsuch at all, not even the slightest peep,
in the standard final-drafts. There are several lingering evidences of
the requirement to have no padding even at the extremes of arrays with
element size 2 and above but all direct statement of such is missing.
The lingering evidence leaves a nondeterminism or unspecified nature to
some matters such as whether sizeof includes any padding at the extremes
of an array or not, while it is explicit about the matter for structs
and unions.

Even the example in the drafts of the use of sizeof array/sizeof
array[0] to determine the number of objects is excluded for arrays with
elements of size 1 due to being unspecified by the standard by the
decree of the limitation in the section on representation that all
representation constraints are found in that section alone and are
otherwise unspecified.

No constraints on representation of arrays is provided in any way
because the contiguousness of elements is mooted outside the
representation subclause, as is the sizeof trick, and the sizeof trick
can only work if the array is represented as contiguous representations
of its elements and is represented with no padding at its extremes,
neither of which is stipulated in the representation subclause that
allows stipulations on the matter only within its own bounds.

Furthermore, the representation stipulation horizon is in the "General"
subclause preventing the "integer types" subclause from effecting
specifications of representations.

If the drafts I can see actually reflect the standards as they were
rather than merely a history of them as the history now is then it was
always impractical to use ISO C anywhere a system had to be safe to use
and nearly all advice from outside the standard was unreliable and some
of the advice within it. An implementers document for C implementations
that ought be implemented but ought not have any programs to translate.

I have to recommend avoiding it everywhere that matters.

-- 
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]

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

On Mon 1/12/2026 9:36 AM, Michael S wrote:
> But I was interested in the "opinion" of C Standard rather than of gcc
> compiler.
> Is it full nasal UB or merely "implementation-defined behavior"?

It is full nasal UB per the standard. And, of course, it is as 
"implementation-defined" as any other UB in a sense that the standard 
permits implementations to _extend_ the language in any way they please, 
as long as they don't forget to issue diagnostics when diagnostics are 
required (by the standard).

>> Perhaps there's a switch in GCC that would outlaw the classic "struct
>> hack"... But in any case, it is not prohibited by default for
>> compatibility with pre-C99 code.
>>
> 
> gcc indeed has something of this sort : -fstrict-flex-arrays=3
> But at the moment it does not appear to affect code generation [in this
> particular example].

Yeah... I tried both the command-line setting and the attribute. No 
effect on the code though.

-- 
Best regards,
Andrey

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

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

On 2026-01-13 11:11, Andrey Tarasevich wrote:
> On Mon 1/12/2026 9:36 AM, Michael S wrote:
>> But I was interested in the "opinion" of C Standard rather than of gcc
>> compiler.
>> Is it full nasal UB or merely "implementation-defined behavior"?
> 
> ... And, of course, it is as 
> "implementation-defined" as any other UB in a sense that the standard 
> permits implementations to _extend_ the language in any way they please, 
> as long as they don't forget to issue diagnostics when diagnostics are 
> required (by the standard).

"implementation defined" is a term defined by the standard. It does not 
carry it's ordinary English definition "defined by the implementation". 
Instead, it means "unspecified behavior where each implementation 
documents how the choice is made". Unless the standard explicity says 
that the behavior is implementation-defined, the fact that any 
particular implementation chooses to define it is irrelevant.

>>> Perhaps there's a switch in GCC that would outlaw the classic "struct
>>> hack"... But in any case, it is not prohibited by default for
>>> compatibility with pre-C99 code.

The struct hack has always technically had undefined behavior, but in 
practice almost all C90 implementations allowed it to work. In C99 
flexible array members were added, which allows the struct hack to work 
with fully-defined behavior using slightly different syntax. The struct 
hack itself is still just as undefined as it ever was, and because of 
the invention of flexible array members, is increasingly likely to not 
be supported.

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

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

Andrey Tarasevich <noone@noone.net> writes:

> On Mon 1/12/2026 9:36 AM, Michael S wrote:
>
>> But I was interested in the "opinion" of C Standard rather than of gcc
>> compiler.
>> Is it full nasal UB or merely "implementation-defined behavior"?
>
> It is full nasal UB per the standard.  And, of course, it is as
> "implementation-defined" as any other UB in a sense that the standard
> permits implementations to _extend_ the language in any way they
> please, as long as they don't forget to issue diagnostics when
> diagnostics are required (by the standard).

There are two schools of thought on that question.  For example, if
an implementation extends the ISO standard by adding a syntax rule,
then using a construct following the added rule does not violate the
syntax and hence no diagnostic is required.  Conversely, it would be
silly for the C standard to say extensions are allowed if what the
extensions do could be done anyway under the umbrella of undefined
behavior (after a diagnostic is issued).  The point of saying the
standard allows extensions is so that an implementation may decline
to issue a diagnostic in certain cases where one would otherwise be
required.

I'm not claiming that this view is the only view possible, only that
it is consistent with what is said in the C standard.

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

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

On 2026-01-12 12:36, Michael S wrote:
> On Mon, 12 Jan 2026 08:03:31 -0800
> Andrey Tarasevich <noone@noone.net> wrote:
>
>> On Mon 1/12/2026 6:28 AM, Michael S wrote:
>>>
>>> According to C Standard, access to p->table[4] in foo1() is UB.
>>> ...
>>> Now the question.
>>> What The Standard says about foo2() ? Is there UB in foo2() as
>>> well?
...
>>> gcc code generator does not think so.

When the behavior is undefined, there's no such thing as incorrect 
generated code. In particular, undefined behavior includes the 
possibility of your code producing precisely the same behavior that you 
incorrectly thought it was required to have.

> Do you have citation from the Standard?

table[4] is defined as equivalent to *(table+4), and and the relevant 
rule for that expression is "If the addition or subtraction produces
an overflow, the behavior is undefined." (6.5.7p9)

...
> But I was interested in the "opinion" of C Standard rather than of gcc
> compiler.
> Is it full nasal UB or merely "implementation-defined behavior"?

UB.

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

#396383 — 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.

OK - so how do you want it to be defined? I've used languages where 
table[n] for n>3 would have exactly the same effect as table[3], and 
table[n] for n<0 would have exactly the same effect as table[0]. I've 
seen algorithms that were actually simplified by relying upon this behavior.

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

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

On Mon, 12 Jan 2026 20:35:09 -0500
"James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> 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.  
> 
> OK - so how do you want it to be defined? I've used languages where 
> table[n] for n>3 would have exactly the same effect as table[3], and 
> table[n] for n<0 would have exactly the same effect as table[0]. I've 
> seen algorithms that were actually simplified by relying upon this
> behavior.

I want "my" dialect to be based on abstract machine with flat memory
model. All variables, except for automatic variables which address
was never taken by the program, are laid upon one big implicit
array of char. 
For my purposes, Harvard abstract machine is sufficient. 
I am sure that there are multiple people that would want option for Von
Neumann abstract machine, i.e. for program code to be laid over the same
implicit array as variables, with as many things defined in the
standard as practically possible. My aspirations do not go that far.

In specific case of 'struct bar1', it means that I want p->table[4:7] to
be absolute equivalents of p->other_table[0:3]. For p->table[n] where n
< 0 or n > 7,  I want generated code to access respective locations in
implicit underlying array. Whether resulting behavior defined or
undefined would depend on the specifics of the caller.

If you say that "my" dialect is less optimizable than Standard C then
my answer is "Yes, I know and I don't care". 

If you say that "my" dialect removes certain potential for detection of
buffer overflows by compiler then my answer is "Generally, yes, and it's
not great, but I consider it a fair price.". Pay attention that there
are still plenty of places where compiler can warn, like in majority of
automatic and static arrays. In other situations bound checking can be
enabled at spot by special attribute.

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

#396396

On 01/01/2026 21:54, highcrew wrote:
> do I really want to be efficiently
> wrong?

If you wanted to give up efficiency to be not wrong you would have taken
more care over writing your loop. You didn't therefore the compiler
reasonably acts accordingly.

You /may/ write a static analyser despite the inefficiency of doing so.
You /may/ give the compiler a flag to help you more.

Consider the problems of making changes to the program unpredictable in
terms of development cost! If the compiler issues a diagnostic for some
programs but not others based merely on whether it /can/ the wider
process is impacted even when predictability is essential and
non-compiler methods are anyway employed to avoid errors.

That is: which choices are encoded into the compiler is a preference.
Which choices are given to you for nothing is the compiler author's
preference.

-- 
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] | [standalone]

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

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

csiph-web