On 04/01/2026 00:25, highcrew wrote:
On 1/4/26 12:15 AM, highcrew wrote:
I have a horrible question now, but that's for a
separate question...
And the question is:
Embedded systems. Address 0x00000000 is mapped to the flash.
I want to assign a pointer to 0x00000000 and dereference it to
read the first word.
That's UB.
How do I?
Now I guess that an embedded compiler targeting that certain
architecture where dereferencing 0 makes sense will not treat
it as UB. But it is for sure a weird corner case.
There are some common misconceptions about null pointers in C. A "null pointer" is the result of converting a "null pointer constant", or
another "null pointer", to a pointer type. A null pointer constant is either an integer constant expression with the value 0 (such as the
constant 0, or "1 - 1"), or "nullptr" in C23. You can use "NULL" from <stddef.h> as a null pointer constant.
So if you write "int * p = 0;", then "p" holds a null pointer. If you
write "int * p = (int *) sizeof(*p); p--;" then "p" does not hold a null pointer, even though it will hold the value "0".
On virtually all real-world systems, including all embedded systems I
have ever known (and that's quite a few), null pointers correspond to
the address 0. But that does not mean that dereferencing a pointer
whose value is 0 is necessarily UB.
And even when dereferencing a pointer /is/ UB, a compiler can handle it
as defined if it wants.
I think that if you have a microcontroller with code at address 0, and a pointer of some object type (say, "const uint8_t * p" or "const uint32_t
* p") holding the address 0, then using that to read the flash at that address is UB. But it is not UB because "p" holds a null pointer - it
may or may not be a null pointer. It is UB because "p" does not point
to an object.
In practice, I have never seen an embedded compiler fail to do the
expected thing when reading flash from address 0. (Typical use-cases
are for doing CRC checks or signature checks on code, or for reading the initial stack pointer value or reset vector of the code.) If you want
to be more confident, use a pointer to volatile type.
Putting volatile qualifier on p gives working code, but apparently
disables optimization. Also, this looks fragile. So if I needed
to access address 0 I probably would use assembly routine to do this.
On 04/01/2026 12:51, highcrew wrote:
On 1/4/26 2:10 AM, Paul J. Lucas wrote:
Perhaps a slightly better explanation of the same example:
https://medium.com/@pauljlucas/undefined-behavior-in-c-and-c-
f30844f20e2a
That one starts off with a bit of a jumble of misconceptions.
To start with, "undefined behaviour" does not exist because of
compatibility issues or the merging of different C variations into one standard C.
The C standard is simply somewhat unusual in that it is more explicit
about UB than many languages' documentation. And being a language
intended for maximally efficient code, C leaves a number of things as UB where other languages might throw an exception or have other error
handling.
Implementation defined behaviour is /not/ "bad" - pretty much all
programs rely on implementation-defined behaviour such as the size of
"int", character sets used, etc. Relying on implementation-defined behaviour reduces the portability of code, but that is not necessary a
bad thing.
And while it is true that UB is "worse" than either implementation-
defined behaviour or unspecified behaviour, it is not for either of the reasons given. The *nix program "date" does not need to contain UB in order to produce different results at different times.
It also makes the mistake common in discussions of UB optimisations of concluding that the optimisation makes the code "wrong". Optimisations, such as the example of the "assign_not_null" function, are "logicallyWhat the author meant is that optimization can make UB manifest more
valid" and /correct/ from the given source code. Optimisations have not made the code "wrong", nor has the compiler. The source code is correct for a given validity subset of its parameter types, and the object code
is correct for that same subset. If the source code is intended to work over a wider range of inputs, then it is the source code that is wrong -
not the optimiser or the optimised code.
On Sun, 4 Jan 2026 14:38:00 +0100, highcrew wrote:
Not differently from halting problem: sure, it is theoretically
impossible to understand if a program will terminate, but in
practical terms, if you expect it to take less than 1 second and it
takes more than 10, you area already hitting ^C and conjecturing
that something went horribly wrong :D
What do Windows users hit instead of CTRL/C? Because CTRL/C means
something different to them, doesn’t it?
On 1/5/26 6:39 AM, David Brown wrote:
On 04/01/2026 12:51, highcrew wrote:
On 1/4/26 2:10 AM, Paul J. Lucas wrote:
Perhaps a slightly better explanation of the same example:
https://medium.com/@pauljlucas/undefined-behavior-in-c-and-c-
f30844f20e2a
That one starts off with a bit of a jumble of misconceptions.
To start with, "undefined behaviour" does not exist because of
compatibility issues or the merging of different C variations into one
standard C.
...
The C standard is simply somewhat unusual in that it is more explicit
about UB than many languages' documentation. And being a language
intended for maximally efficient code, C leaves a number of things as
UB where other languages might throw an exception or have other error
handling.
Other languages had the luxury of doing that. As the article pointed
out, C had existed for over a decade before the standard and there were
many programs in the wild that relied on their existing behaviors. By
this time, the C standard could not retroactively "throw an exception or
have other error handling" since it would have broken those programs, so
it _had_ to leave many things as UB explicitly. Hence, the article
isn't wrong.
Implementation defined behaviour is /not/ "bad" - pretty much all
programs rely on implementation-defined behaviour such as the size of
"int", character sets used, etc. Relying on implementation-defined
behaviour reduces the portability of code, but that is not necessary a
bad thing.
It's "bad" if a naive programmer isn't aware it's implementation defined
and just assumes it's defined however it's defined on his machine.
And while it is true that UB is "worse" than either implementation-
defined behaviour or unspecified behaviour, it is not for either of
the reasons given. The *nix program "date" does not need to contain
UB in order to produce different results at different times.
Sure, but the article didn't mean such cases.
It meant for cases like
incrementing a signed integer past INT_MAX. A program could
legitimately give different answers for the same line of code at
different times.
It also makes the mistake common in discussions of UB optimisations ofWhat the author meant is that optimization can make UB manifest more bizarrely in ways than not optimizing wouldn't. Code that contains UB
concluding that the optimisation makes the code "wrong".
Optimisations, such as the example of the "assign_not_null" function,
are "logically valid" and /correct/ from the given source code.
Optimisations have not made the code "wrong", nor has the compiler.
The source code is correct for a given validity subset of its
parameter types, and the object code is correct for that same subset.
If the source code is intended to work over a wider range of inputs,
then it is the source code that is wrong - not the optimiser or the
optimised code.
is always wrong.
What the author meant is that optimization can make UB manifest more bizarrely in ways than not optimizing wouldn't. Code that contains UB
is always wrong.
Other languages had the luxury of doing that. As the article pointed
out, C had existed for over a decade before the standard and there
were many programs in the wild that relied on their existing
behaviors. By this time, the C standard could not retroactively
"throw an exception or have other error handling" since it would have
broken those programs, so it _had_ to leave many things as UB
explicitly. Hence, the article isn't wrong.
I get the following assembly:
00000000 <read_at0>:
0: b108 cbz r0, 6 <read_at0+0x6>
2: 2000 movs r0, #0
4: 4770 bx lr
6: 6803 ldr r3, [r0, #0]
8: deff udf #255 @ 0xff
a: bf00 nop
So compiler generates actiual access, but then, instead of returning
the value it executes undefined opcode. Without test for null
pointer I get simple access to memory.
When it comes to invalid (or missing, in C++) `return` statements,
GCC tends to adhere to a "punitive" approach in optimized code - it
injects instructions to deliberately cause a crash/segfault in such
cases.
Clang on the other hand tends to stick to the uniform approach based
on the "UB cannot happen" methodology, i.e. your code sample would
be translated under "p is never null" assumption, and the function
will fold into a simple unconditional `return 0`.
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!
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.
After observing that, I think the right question is something like
"Given that compilers act in these surprising ways, how should I
protect my code so that it doesn't fall prey to the death-by-UB
syndrome, or what can I do to diagnose a possibly death-by-UB
situation when a strange bug crops up?" I don't pretend to have
good answers to these questions. The best advice I can give
(besides seeking help from others with more experience) is to be
persistent, and to realize that the skills needed for combating a
death-by-UB syndrome are rather different from the skills needed
for regular programming. I have been in the situation of being
made responsible for finding and correcting a death-by-UB kind of
symptom, and what's worse in programming environment where I
didn't have a great deal of familiarity or experience. Despite
those drawbacks the bug got diagnosed and fixed, and I attribute
that result mostly to tenacity and by being willing to consider
unusual or unfamiliar points of view.
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 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
It is UB, what the implement is irrevant.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.
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.
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:
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.
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.
// code portable among several types of systems:
switch (sizeof var) {
case 2: ...
case 4: ...
case 8: ...
}
sizeof var is a compile time constant expected to be 2, 4 or 8 bytes.
The other cases are unreachable code.
Suppose every time the compiler eliminates unreachable code, it
issues a diagnostic "foo.c:42: 3 lines of unreachable code removed".
That would be annoying when the programmer knows about dead code
elimination and is counting on it.
We also have to consider that not all code is written directly by
hand.
Code generation techniques (including macros) can produce "weird" code
in some of their corner cases. The code is correct, and it would take
more complexity to identify those cases and generate more idiomatic
code; it is left to the compiler to clean up.
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.
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.
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.
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.
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.
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.
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 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.]
Now the question.
What The Standard says about foo2() ? Is there UB in foo2() as well?
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.
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.
table plays a role FMA. A lot of code depends on such pattern. It'srather standard practice in communication programming. Esp. so in C90,
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.
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.
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.
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?
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.
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".described as one myself. It means those who are knowledgeable about what
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
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.
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].
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?
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.
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.
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"?
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].
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)."
do I really want to be efficiently
wrong?
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.
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.
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.
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. ...
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).
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).
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.
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.
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.
Do you have citation from the Standard?
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"?
May be. But it's not expressed by gcc code generator or by any wranings.
So, how can we know?
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?
On Mon, 12 Jan 2026 21:09:25 -0500That's the difference - I did understand. In your struct, other_table is
"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 :(
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.
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.
Combining these, and padding requirements, you can definedly reach
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.
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!!!
Perhaps the exception Tristan was referring to (though it doesn't apply
to indexing) is this, in N3220 6.5.10p7:
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
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.
No one can claim that the OOB situation in the code has escaped identification, because a code-eliminating optimization was predicated
on it.
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.
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?
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];
};
};
"Each non-bit-field member of a structure or union object is alignedI'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 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]".
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];
};
};
"Each non-bit-field member of a structure or union object is alignedI'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 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.
On 14/01/2026 23:43, Keith Thompson wrote:...
They follow from a couple of facts: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!
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.
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.
[...]
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.
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.
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.
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.
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?
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,097 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 21:13:47 |
| Calls: | 14,089 |
| Files: | 187,111 |
| D/L today: |
1,311 files (437M bytes) |
| Messages: | 2,490,428 |