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

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

On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:
> 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)
> 

Does this allow different alignment rules for a type when it is 
stand-alone, in an array, or in a struct?  I don't think so - I have 
always interpreted this to mean that the alignment is tied to the type, 
not where the type is used.

Thus if "int" has 4-byte size and 4-byte alignment, and you have :

	struct X {
		char a;
		int b;
		int c;
		int ds[4];
	}

then there will be 3 bytes of padding between "a" and "b", but cannot be 
any between "b" and "c" or between "c" and "ds".

Even if you have a weird system that has, say, 3-byte "int" with 4-byte 
alignment, where you would have a byte of padding between "b" and "c", 
you would have the same padding there as between "ds[0]" and "ds[1]".

(None of this means you are allowed to access data with "p[i]" or "p + 
i" outside of the range of the object that "p" points to or into.)

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

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

David Brown <david.brown@hesbynett.no> wrote:
> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:
>> 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)
>> 
> 
> Does this allow different alignment rules for a type when it is 
> stand-alone, in an array, or in a struct?  I don't think so - I have 
> always interpreted this to mean that the alignment is tied to the type, 
> not where the type is used.
> 
> Thus if "int" has 4-byte size and 4-byte alignment, and you have :
> 
>        struct X {
>                char a;
>                int b;
>                int c;
>                int ds[4];
>        }
> 
> then there will be 3 bytes of padding between "a" and "b", but cannot be 
> any between "b" and "c" or between "c" and "ds".

Why not?  Assuming 4 byte int with 4 byte alignment I see nothing
wrong with adding 4 byte padding between b and c.  More precisely,
implementation could say that after first int field in a struct
there is always 4 byte padding.  AFAICS alignment constraints
and initial segment rule are satified, padding is not at start
of the struct.  Are there any other restrictions?
 
> Even if you have a weird system that has, say, 3-byte "int" with 4-byte 
> alignment, where you would have a byte of padding between "b" and "c", 
> you would have the same padding there as between "ds[0]" and "ds[1]".
> 
> (None of this means you are allowed to access data with "p[i]" or "p + 
> i" outside of the range of the object that "p" points to or into.)
> 
>> 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.
>> 
> 

-- 
                              Waldek Hebisch

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

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

antispam@fricas.org (Waldek Hebisch) writes:

> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 14/01/2026 04:19, James Russell Kuyper Jr.  wrote:
>>
>>> 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)
>>
>> Does this allow different alignment rules for a type when it is
>> stand-alone, in an array, or in a struct?  I don't think so - I have
>> always interpreted this to mean that the alignment is tied to the type,
>> not where the type is used.
>>
>> Thus if "int" has 4-byte size and 4-byte alignment, and you have :
>>
>>        struct X {
>>                char a;
>>                int b;
>>                int c;
>>                int ds[4];
>>        }
>>
>> then there will be 3 bytes of padding between "a" and "b", but cannot be
>> any between "b" and "c" or between "c" and "ds".
>
> Why not?  Assuming 4 byte int with 4 byte alignment I see nothing
> wrong with adding 4 byte padding between b and c.

Right.  As long as alignment requirements are satisfied, an
implementation is free to put as much padding as it wants
between struct members.

> More precisely,
> implementation could say that after first int field in a struct
> there is always 4 byte padding.  AFAICS alignment constraints
> and initial segment rule are satified, padding is not at start
> of the struct.  Are there any other restrictions?

There are some consistency requirements with respect to other
struct types that have a common starting sequence of members.
Basically, as long as the rules stay the same from struct to
struct (and alignment rules are respected), then there can be
however much padding the implementation chooses to add, at any
point between struct members (with some additional restrictions
for bitfields).

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

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

David Brown <david.brown@hesbynett.no> writes:
> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:
>> 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)
>
> Does this allow different alignment rules for a type when it is
> stand-alone, in an array, or in a struct?  I don't think so - I have
> always interpreted this to mean that the alignment is tied to the
> type, not where the type is used.

Note that the alignof operator applies to a type, not to an expression
or object.

> Thus if "int" has 4-byte size and 4-byte alignment, and you have :
>
> 	struct X {
> 		char a;
> 		int b;
> 		int c;
> 		int ds[4];
> 	}
>
> then there will be 3 bytes of padding between "a" and "b", but cannot
> be any between "b" and "c" or between "c" and "ds".

There can be arbitrary padding between struct members, or after the last
member.  Almost(?) all implementations add padding only to satisfy
alignment requirements, but the standard doesn't state any restrictions.
There can be no padding before the first member, and offsets of members
must be increasing.

If alignof (int) is 4, a compiler must place an int object at an address
that's a multiple of 4.  It's free to place it at a multiple of 8, or
16, if it chooses.

> Even if you have a weird system that has, say, 3-byte "int" with
> 4-byte alignment, where you would have a byte of padding between "b"
> and "c", you would have the same padding there as between "ds[0]" and
> "ds[1]".

sizeof (int) == 3 and alignof (int) == 4 is not possible.  Each type's
size is a multiple of its alignment.  There is no padding between array
elements.

[...]

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

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

On 14/01/2026 23:43, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:
>>> 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)
>>
>> Does this allow different alignment rules for a type when it is
>> stand-alone, in an array, or in a struct?  I don't think so - I have
>> always interpreted this to mean that the alignment is tied to the
>> type, not where the type is used.
> 
> Note that the alignof operator applies to a type, not to an expression
> or object.
> 
>> Thus if "int" has 4-byte size and 4-byte alignment, and you have :
>>
>> 	struct X {
>> 		char a;
>> 		int b;
>> 		int c;
>> 		int ds[4];
>> 	}
>>
>> then there will be 3 bytes of padding between "a" and "b", but cannot
>> be any between "b" and "c" or between "c" and "ds".
> 
> There can be arbitrary padding between struct members, or after the last
> member.  Almost(?) all implementations add padding only to satisfy
> alignment requirements, but the standard doesn't state any restrictions.
> There can be no padding before the first member, and offsets of members
> must be increasing.
> 

On closer reading, I agree with you here.  I find it a little surprising 
that this is not implementation-defined.  If an implementation can 
arbitrarily add extra padding within a struct, it severely limits the 
use of structs in contexts outside the current translation unit.

> If alignof (int) is 4, a compiler must place an int object at an address
> that's a multiple of 4.  It's free to place it at a multiple of 8, or
> 16, if it chooses.
> 
>> Even if you have a weird system that has, say, 3-byte "int" with
>> 4-byte alignment, where you would have a byte of padding between "b"
>> and "c", you would have the same padding there as between "ds[0]" and
>> "ds[1]".
> 
> sizeof (int) == 3 and alignof (int) == 4 is not possible.  Each type's
> size is a multiple of its alignment.  There is no padding between array
> elements.
> 

I have not, as yet, found a justification for those statements in the 
standards.  But I'll keep looking!

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

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

On 2026-01-15 05:45, David Brown wrote:
> On 14/01/2026 23:43, Keith Thompson wrote:
...
>> sizeof (int) == 3 and alignof (int) == 4 is not possible.  Each type's
>> size is a multiple of its alignment.  There is no padding between array
>> elements.
>>
> 
> I have not, as yet, found a justification for those statements in the 
> standards.  But I'll keep looking!
They follow from a couple of facts:
Each element in an array of type T must be correctly aligned for an
object of type T.
No space is allowed between the elements of an array. Note, in
particular, that this implies that if a type uses only 3 bytes, but has
an alignment requirement of 2, it must be padded to a length of 4 bytes,
and sizeof(T) must reflect that size, and not the number of bytes that
the type actually uses.

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

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

David Brown <david.brown@hesbynett.no> writes:
> On 14/01/2026 23:43, Keith Thompson wrote:
[...]
>> There can be arbitrary padding between struct members, or after the
>> last member.  Almost(?) all implementations add padding only to
>> satisfy alignment requirements, but the standard doesn't state any
>> restrictions.  There can be no padding before the first member, and
>> offsets of members must be increasing.
>
> On closer reading, I agree with you here.  I find it a little
> surprising that this is not implementation-defined.  If an
> implementation can arbitrarily add extra padding within a struct, it
> severely limits the use of structs in contexts outside the current
> translation unit.

In practice, struct layouts are (I think) typically specified by
a system's ABI, and ABIs generally permit/require only whatever
padding is necessary to meet alignment requirements.

And I think C has rules about type compatibility that are intended to
cover the same struct definition being used in different translation
units within a program, though I'm too lazy to look up the details.

[...]

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

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

On 15/01/2026 13:04, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/01/2026 23:43, Keith Thompson wrote:
> [...]
>>> There can be arbitrary padding between struct members, or after the
>>> last member.  Almost(?) all implementations add padding only to
>>> satisfy alignment requirements, but the standard doesn't state any
>>> restrictions.  There can be no padding before the first member, and
>>> offsets of members must be increasing.
>>
>> On closer reading, I agree with you here.  I find it a little
>> surprising that this is not implementation-defined.  If an
>> implementation can arbitrarily add extra padding within a struct, it
>> severely limits the use of structs in contexts outside the current
>> translation unit.
> 
> In practice, struct layouts are (I think) typically specified by
> a system's ABI, and ABIs generally permit/require only whatever
> padding is necessary to meet alignment requirements.

Sure.  I would be very surprised to see a real compiler add extra 
padding in a struct, beyond what was needed for alignment.  And real 
compilers usually use well-documented ABI's that go beyond the 
requirements of C's implementation-defined behaviours in their detail. 
It just strikes me as a little odd that the standard says 
implementations must document things like how they split bit-fields 
between addressable units, but makes no requirements at all about how 
much extra padding they can have between struct fields.

> 
> And I think C has rules about type compatibility that are intended to
> cover the same struct definition being used in different translation
> units within a program, though I'm too lazy to look up the details.
> 
> [...]
> 

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

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

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

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 14/01/2026 23:43, Keith Thompson wrote:
>
> [...]
>
>>> There can be arbitrary padding between struct members, or after the
>>> last member.  Almost(?) all implementations add padding only to
>>> satisfy alignment requirements, but the standard doesn't state any
>>> restrictions.  There can be no padding before the first member, and
>>> offsets of members must be increasing.
>>
>> On closer reading, I agree with you here.  I find it a little
>> surprising that this is not implementation-defined.  If an
>> implementation can arbitrarily add extra padding within a struct, it
>> severely limits the use of structs in contexts outside the current
>> translation unit.
>
> In practice, struct layouts are (I think) typically specified by
> a system's ABI, and ABIs generally permit/require only whatever
> padding is necessary to meet alignment requirements.
>
> And I think C has rules about type compatibility that are intended to
> cover the same struct definition being used in different translation
> units within a program, though I'm too lazy to look up the details.

In fact, the rules in the C standard imply that any two struct
types that have members of the same types and in the same order
have the same layout (conceivably with different amounts of
padding at the end), regardless of whether the two struct types
are compatible or not.

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

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

David Brown <david.brown@hesbynett.no> writes:
>On 14/01/2026 23:43, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:

>> There can be arbitrary padding between struct members, or after the last
>> member.  Almost(?) all implementations add padding only to satisfy
>> alignment requirements, but the standard doesn't state any restrictions.
>> There can be no padding before the first member, and offsets of members
>> must be increasing.
>> 
>
>On closer reading, I agree with you here.  I find it a little surprising 
>that this is not implementation-defined.  If an implementation can 
>arbitrarily add extra padding within a struct, it severely limits the 
>use of structs in contexts outside the current translation unit.

Including representing typical networking packet headers as structs.

Fortunately, most C compilers have some form of __attribute__((packed))
to inform the compiler that the structure layout should not be padded.

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

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

On 15/01/2026 16:10, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/01/2026 23:43, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:
> 
>>> There can be arbitrary padding between struct members, or after the last
>>> member.  Almost(?) all implementations add padding only to satisfy
>>> alignment requirements, but the standard doesn't state any restrictions.
>>> There can be no padding before the first member, and offsets of members
>>> must be increasing.
>>>
>>
>> On closer reading, I agree with you here.  I find it a little surprising
>> that this is not implementation-defined.  If an implementation can
>> arbitrarily add extra padding within a struct, it severely limits the
>> use of structs in contexts outside the current translation unit.
> 
> Including representing typical networking packet headers as structs.
> 
> Fortunately, most C compilers have some form of __attribute__((packed))
> to inform the compiler that the structure layout should not be padded.

I very rarely find any benefit in using packed structs - typically only 
if the layout was originally designed without thought for alignment, or 
where the maximum considered alignment was smaller than on modern 
systems.  My preference is to add padding fields manually, then have a 
static_assert on the size of the struct to check for problems.  That 
does not necessarily mean the code is always portable, but at least if 
it is not going to work on a given platform, I get a compile-time error 
rather than a mystical bug!

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

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

On 12/01/2026 15:58, bart wrote:
> 
>  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.

IIRC indexing a table follows the rules of pointers and doing so outside
of a table's bounds is generally U/B except for very peculiar specific
cases. You can do it in a struct across members /sometimes/ because a
struct is a single object. In general it depends on whether your pointer
arithmetic has been written such that it matches the layout of the
structure.

IIRC there is a standard version upon which certain combinations are
guaranteed to be packed, the examples above /might/ exemplify some of them.


This is another matter:

int table[2][4];
(table[0][4] == v);

IIRC, that /is/ a valid reference to the first element of the second
table and is easier to rely on than other cases that might be valid.

ie table[0][4] is equivalent to table[1][0] because both just juggle
pointers around within a single object in a way that's a valid pointer
at every moment (which is a stronger condition than what's actually
required anyway).

*(*(table + 0) + 4) is /functionally/ equivalent to *(*(table + 1) + 0)
and there is validity assured by the way table is defined: table[1] is
not a separate object from table[0] and there can be no padding by a
peculiarity of the rules even for quite old versions of the standard, I
think even C89 but I bet there are others with better memories.

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

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

On 2026-01-13 16:54, Tristan Wibberley wrote:
> On 12/01/2026 15:58, bart wrote:
>>
>>   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;
>>   }
...
> IIRC indexing a table follows the rules of pointers and doing so outside
> of a table's bounds is generally U/B except for very peculiar specific
> cases. You can do it in a struct across members /sometimes/ because a
> struct is a single object. ...

No, there is no such exception in the standard. It is still undefined 
behavior. One of the most annoying ways undefined behavior can manifest 
is that you get exactly the same behavior that you incorrectly thought 
you were guaranteed to get. That's a problem, because it can leave you 
unaware of your error.

> IIRC there is a standard version upon which certain combinations are
> guaranteed to be packed, the examples above /might/ exemplify some of them.

Elements of the same array are stored consecutively, with no gaps 
between them. Consecutive bit-fields whose sizes allow them to be 
allocated within the same allocation unit must be allocated from the 
same allocation unit. Note that the size of the allocation unit is 
unspecified. I can't think of any other situations where the standard 
addresses packing. Many implementations provide non-standard extensions 
that give you control over packing.

> This is another matter:
> 
> int table[2][4];
> (table[0][4] == v);
> 
> IIRC, that /is/ a valid reference to the first element of the second
> table and is easier to rely on than other cases that might be valid.

No, table[0][4] violates 6.5.7p9. People have often had trouble seeing 
that this is the case - asking about the issue was the very first 
question I posed to comp.std.c a couple of decades ago. As a result, 
starting in C99 an example was added (currently Annex J.2 "undefined 
behavior" item 39) as follows:

"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])".

This makes it clear that it's the length of the sub-array that limits 
how much you can add to pointers that point at elements of the sub-array.

> ie table[0][4] is equivalent to table[1][0] because both just juggle
> pointers around within a single object in a way that's a valid pointer
> at every moment (which is a stronger condition than what's actually
> required anyway).

Yes, table[0]+4 is required to compare equal to table[1], but 
table[0][4] has undefined behavior, while table[1][0] does not.

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

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

"James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> writes:
> On 2026-01-13 16:54, Tristan Wibberley wrote:
[...]
>> IIRC indexing a table follows the rules of pointers and doing so
>> outside of a table's bounds is generally U/B except for very peculiar
>> specific cases. You can do it in a struct across members /sometimes/
>> because a struct is a single object. ...
>
> No, there is no such exception in the standard. It is still undefined
> behavior. One of the most annoying ways undefined behavior can
> manifest is that you get exactly the same behavior that you
> incorrectly thought you were guaranteed to get. That's a problem,
> because it can leave you unaware of your error.
[...]

Perhaps the exception Tristan was referring to (though it doesn't apply
to indexing) is this, in N3220 6.5.10p7:

    Two pointers compare equal if and only if both are null pointers,
    both are pointers to the same object (including a pointer to an
    object and a subobject at its beginning) or function, both are
    pointers to one past the last element of the same array object,
    or one is a pointer to one past the end of one array object and
    the other is a pointer to the start of a different array object
    that happens to immediately follow the first array object in
    the address space.

with a footnote:

    Two objects can be adjacent in memory because they are adjacent
    elements of a larger array or adjacent members of a structure
    with no padding between them, or because the implementation
    chose to place them so, even though they are unrelated. If prior
    invalid pointer operations (such as accesses outside array
    bounds) produced undefined behavior, subsequent comparisons
    also produce undefined behavior.

The idea, I think, is that without that paragraph, given something like
this:

#include <stdio.h>
int main(void) {
    struct {
        int a[10];
        int b[10];
    } obj;

    printf("obj.a+10 %s obj.b\n",
           obj.a+10 == obj.b ? "==" : "!=");
}

the compiler would have to go out of its way to treat obj.a+10 and obj.b
as unequal.  (The output on my system is "obj.a+10 == obj.b", but the
pointers could be unequal if there's padding between a and b -- which is
unlikely.)

(I reported a relevant bug in gcc, where for objects that happen to be
adjacent the addresses are reported as unequal with -O1 or higher; the
gcc maintainers disagreed.
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611>)

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

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

On 14/01/2026 06:02, Keith Thompson wrote:
> Perhaps the exception Tristan was referring to (though it doesn't apply
> to indexing) is this, in N3220 6.5.10p7:

I think I was referring either to C++ or to an inference somebody else
had made once upon a time - or else the historical final-drafts
documents are different now than they were :/ Possibly K&R C specified
something more defined than ISO C, I have lent my book out so I can't
check. It was supposedly updated to ISO C. Possibly it was pre-K&R C or
implementation specific that I picked up as a teen and my uni professor
cemented it in my mind as correct C when he gave me 100% for an
assignment in which I used it - and he was a stickler regarding
undefined behaviour.

Furthermore, to prevent similar lingering misconceptions indexing is not
specified in the standards I'm looking at beyond that it's just pointer
arithmetic - that is, a pointer derived from an array-name may not be
used with pointer arithmetic /alone/ that adjusts the pointer down by
any nor up by more than the number of elements in the array + 1, and if
adjusted up by num_elements it can't be used with *. Note that in some
standards' final-drafts I see that intermediate (perhaps, generally,
non-lvalue) pointers may be created by pointer arithmetic when they are
de-created again - and perhaps the pattern of arithmetic is very limited.

Some standard version says if you convert it to a large enough integer
type and back then it is not undefined behaviour but
"implementation-specific" instead, which is a new term on me
("implementation-specific" is not the same term as "implementation
specified").


... pointer equality snipped ...


> The idea, I think, is that without that paragraph, given something like
> this:
> 
> #include <stdio.h>
> int main(void) {
>     struct {
>         int a[10];
>         int b[10];
>     } obj;
> 
>     printf("obj.a+10 %s obj.b\n",
>            obj.a+10 == obj.b ? "==" : "!=");
> }
> 
> the compiler would have to go out of its way to treat obj.a+10 and obj.b
> as unequal

No it wouldn't. The standard could have just made the comparison
undefined behaviour or unspecified, or implementation specified in all
those cases when dereferencing was undefined or unspecified.

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

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

On Wed, 14 Jan 2026 14:24:08 +0000
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk>
wrote:

> On 14/01/2026 06:02, Keith Thompson wrote:
> 
> 
> > The idea, I think, is that without that paragraph, given something
> > like this:
> > 
> > #include <stdio.h>
> > int main(void) {
> >     struct {
> >         int a[10];
> >         int b[10];
> >     } obj;
> > 
> >     printf("obj.a+10 %s obj.b\n",
> >            obj.a+10 == obj.b ? "==" : "!=");
> > }
> > 
> > the compiler would have to go out of its way to treat obj.a+10 and
> > obj.b as unequal  
> 
> No it wouldn't. The standard could have just made the comparison
> undefined behaviour or unspecified, or implementation specified in all
> those cases when dereferencing was undefined or unspecified.
> 

In this particular case both pointers are defined and there is no
dereferencing.

The issues as one above are treated in depth in this paper: 
https://gustedt.wordpress.com/2025/06/30/the-provenance-memory-model-for-c/
Which I naturally didn't read.

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

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

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. However, since this is the trailing array member of 
the struct, GCC does not want to accidentally suppress the classic 
"struct hack". It assumes that quite possibly the pointer passed to the 
function points to a struct object allocated through the "struct hack" 
technique.

Add an extra field after the trailing array and `foo2` will also fold 
into `return 1`, just like `foo1`.

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.

-- 
Best regards,
Andrey

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

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

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.

Do you have citation from the Standard?

> However, since this is the trailing array member
> of the struct, GCC does not want to accidentally suppress the classic 
> "struct hack". It assumes that quite possibly the pointer passed to
> the function points to a struct object allocated through the "struct
> hack" technique.

That much I understand myself.
p->table plays a role FMA. A lot of code depends on such pattern. It's
rather standard practice in communication programming. Esp. so in C90,
when there were no FMA and in C++ where FMA does not exist even today.
Production compiler like gcc has really no option except to handle
it as expected by millions of programmers.

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"?

> 
> Add an extra field after the trailing array and `foo2` will also fold 
> into `return 1`, just like `foo1`.
> 
> 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].

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

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

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.

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

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

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

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 :(

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

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

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

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

csiph-web