Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396062 > unrolled thread
| Started by | highcrew <high.crew3868@fastmail.com> |
|---|---|
| First post | 2026-01-01 22:54 +0100 |
| Last post | 2026-01-13 20:37 +0000 |
| Articles | 20 on this page of 113 — 18 participants |
Back to article view | Back to comp.lang.c
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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-01-02 22:52 +0000 |
| Message-ID | <20260102135350.74@kylheku.com> |
| In reply to | #396062 |
On 2026-01-01, highcrew <high.crew3868@fastmail.com> wrote: > Wouldn't it be more sensible to have a compilation error, or > at least a warning? It would in that case, but it's very difficult to specify that into the language standard as a requirement such that all implementations must produce a diagnostic. If we wanted to diagnose situations similar to the ones in your example program, we would have two departures from the way the language is now. The first is that we would need to formalize the concept of error versus warning diagnostics. Currently there are only diagnostics. Currently, when the implementation is required to diagnose a program, that program is deemed to be incorrect: it violates a syntax or semantic constraint rule. It is not required to be translated, and if it is translated and linked, it doesn't have well-defined behavior at all. Warnings are diagnostics for situations that are not confirmed incorrect, but only suspected. Compilers typically treat some ISO-C-required diagnostics as warnings. For instance, GNU C issues only a warning when pointers are converted without a cast. But ISO C allows it to stop translating. For the situation in your program, it would be unacceptable to have implementations stop translating. We really want just a warning (at least by default; in specific project and situations, developers could elect to treat certain warnings as fatal, even standard-required warnings.) The second new thing is that to diagnose this, we need to make diagnosis dependent on reachability. We want a rule which is something like "whenever the body of a function, or an initializing expression for an external definition reaches an expression which has unconditional undefined behavior that is not an unreachability assertion and not a documented extension, a warning diagnostic must be issued". This "reaches" has a problem because it requires the implementation to solve the halting problem. We should restrict that to just "statically obvious" or "trivial" reachability whereby without having to reason about unknown run-time values, we can infer that a statement or expression is unconditionally reached. This kind of diagnostic would be a good thing in my opinion; just nobody has stepped up to the plate because of the challenges: - introducing the concept of a warning versus error diagnostic. - defining a clear set of rules for trivial reachability which can catch the majority of these situations without too much complexity. (The C++ rules for functions that return value reaching their end without a return statement can be used as inspiration here.) - specifying exactly what "statically obvious" undefined behavior is and how positively determine that a certain expression exhibits it. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | highcrew <high.crew3868@fastmail.com> |
|---|---|
| Date | 2026-01-03 23:47 +0100 |
| Message-ID | <10jc697$1j15f$1@dont-email.me> |
| In reply to | #396094 |
On 1/2/26 11:52 PM, Kaz Kylheku wrote: > On 2026-01-01, highcrew <high.crew3868@fastmail.com> wrote: > For the situation in your program, it would be unacceptable to have > implementations stop translating. I can somehow get the idea that it is difficult for the compiler to spot the issue, but why do you think it would be unacceptable to stop translating? > We really want just a warning (at > least by default; in specific project and situations, developers > could elect to treat certain warnings as fatal, even standard-required > warnings.) Even a warning would be enough though. Btw, my typical way of working is to enable -Werror while developing, but I don't like to force it in general. That would be an interesting digression, but definitely OT. > The second new thing is that to diagnose this, we need to make > diagnosis dependent on reachability. > > We want a rule which is something like "whenever the body of > a function, or an initializing expression for an external definition > reaches an expression which has unconditional undefined behavior > that is not an unreachability assertion and not a documented > extension, a warning diagnostic must be issued". That's an interesting perspective: reachability. Would you say that the incriminated piece of code is UB only if it is reachable in the final program, therefore it is acceptable to keep it as long as unreachable? Now that I think of it, the __builtin_unreachable() implemented by popular compilers is technically UB *if reached* :) > This kind of diagnostic would be a good thing in my opinion; just > nobody has stepped up to the plate because of the challenges: > > - introducing the concept of a warning versus error diagnostic. > > - defining a clear set of rules for trivial reachability which > can catch the majority of these situations without too much > complexity. (The C++ rules for functions that return value > reaching their end without a return statement can be used > as inspiration here.) > > - specifying exactly what "statically obvious" undefined behavior > is and how positively determine that a certain expression > exhibits it. Now I'm wondering how much work it requires to properly define the rules that the standard mandates! As for me the main take-away is that the detection of certain UB is non-trivial, it would be very evil if the standard was mandating some nearly-impossible task to the compiler! > (The C++ rules for functions that return value > reaching their end without a return statement can be used > as inspiration here.) C++ does *what*?? I'm definitely not up to speed with C++, but I totally have missed that. Could you please tell me the name of this bizarre feature? I *need* to look it up :D -- High Crew
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-04 12:58 +0100 |
| Message-ID | <10jdkkb$1vilu$1@dont-email.me> |
| In reply to | #396123 |
On 03/01/2026 23:47, highcrew wrote:
> On 1/2/26 11:52 PM, Kaz Kylheku wrote:
>> On 2026-01-01, highcrew <high.crew3868@fastmail.com> wrote:
>> For the situation in your program, it would be unacceptable to have
>> implementations stop translating.
>
> I can somehow get the idea that it is difficult for the compiler
> to spot the issue, but why do you think it would be unacceptable
> to stop translating?
>
A C compiler definitely should /not/ stop translating just because it
finds UB like this - at least, not with "normal" compilation flags.
(With additional flags, anything is allowable.)
Run-time UB is only a problem if the running program attempts to execute
it. So it is only really appropriate for it to be treated as a fatal
compile-time error if the compiler knows for sure that it will be
executed (i.e., it can trace all execution paths from the start of
"main" and see that it is inevitably executed). That is clearly
infeasible for the vast majority of such run-time UB.
It is entirely normal that code is full of potential run-time UB :
extern int xs[10];
int foo(int i) { return xs[i]; }
The function "foo" has potential UB - but the compiler should not stop
translating just because you /might/ call it with an inappropriate argument.
Functions that have unavoidable UB, such as the example in this thread,
are not guaranteed to be called - the compiler cannot reasonably refuse
to continue compiling. But it is also fair to say unavoidable UB in a
function is almost certainly a mistake by the programmer, and a warning
message (even without specifying any warning flags) would be a very nice
thing for the compiler to give you.
The C standard requires certain mistakes to require a diagnostic - a
warning or fatal error message. It only does that for things that a
compiler could reasonably be expected to identify, without having to
simulate run-time conditions, or consider multiple translation units at
once.
>> We really want just a warning (at
>> least by default; in specific project and situations, developers
>> could elect to treat certain warnings as fatal, even standard-required
>> warnings.)
>
> Even a warning would be enough though. Btw, my typical way of
> working is to enable -Werror while developing, but I don't like
> to force it in general. That would be an interesting digression,
> but definitely OT.
>
(I too have "-Werror" enabled, at least once my initial builds are
somewhat solidified - it means you can't lose an important warning
message somewhere in the output of your build process.)
>> The second new thing is that to diagnose this, we need to make
>> diagnosis dependent on reachability.
>>
>> We want a rule which is something like "whenever the body of
>> a function, or an initializing expression for an external definition
>> reaches an expression which has unconditional undefined behavior
>> that is not an unreachability assertion and not a documented
>> extension, a warning diagnostic must be issued".
>
> That's an interesting perspective: reachability.
> Would you say that the incriminated piece of code is UB only if it
> is reachable in the final program, therefore it is acceptable
> to keep it as long as unreachable?
>
> Now that I think of it, the __builtin_unreachable() implemented
> by popular compilers is technically UB *if reached* :)
>
"unreachable()" is now standard, in C23. But that may be what Kaz is
referring to as "an unreachability assertion".
And AFAIUI gcc and clang/llvm have an "UB" instruction or statement in
their internal formats, and will use that for "__builtin_unreachable()"
and also when generating code from your example.
>> This kind of diagnostic would be a good thing in my opinion; just
>> nobody has stepped up to the plate because of the challenges:
>>
>> - introducing the concept of a warning versus error diagnostic.
>>
>> - defining a clear set of rules for trivial reachability which
>> can catch the majority of these situations without too much
>> complexity. (The C++ rules for functions that return value
>> reaching their end without a return statement can be used
>> as inspiration here.)
>>
>> - specifying exactly what "statically obvious" undefined behavior
>> is and how positively determine that a certain expression
>> exhibits it.
> Now I'm wondering how much work it requires to properly define
> the rules that the standard mandates!
>
Um, the standard defines the rules - that's the point. So your question
is really "how much work did it take to write the C standard?". I don't
think that's what you meant.
> As for me the main take-away is that the detection of certain UB
> is non-trivial, it would be very evil if the standard was mandating
> some nearly-impossible task to the compiler!
>
The standard is quite lenient on what it requires from C compilers
(though most don't follow all its rules by default). Static warnings
are a matter of quality of implementation, not requirements of the
language. This lets people write relatively small and simple C
compilers if they want, while also giving big toolchains the freedom to
add lots more checking and developer help.
>
> > (The C++ rules for functions that return value
> > reaching their end without a return statement can be used
> > as inspiration here.)
>
> C++ does *what*?? I'm definitely not up to speed with C++, but
> I totally have missed that. Could you please tell me the name
> of this bizarre feature? I *need* to look it up :D
>
I believe the difference is in the behaviour of a function that is
declared to return a value (i.e., not "void") but which exits without a
returning value. In C, this is allowed - but it is UB to attempt to use
the non-existent return value. In C++, it is UB to fail to return a
value - which is far easier for a compiler to diagnose.
So if you have :
int foo(void) { }
int bar(void) { return foo(); }
then in C++, the UB is in the definition of "foo", while in C it is in
the run-time use of "foo" inside "bar".
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-01-03 07:53 -0800 |
| Message-ID | <10jbe1j$1b3h1$2@dont-email.me> |
| In reply to | #396062 |
On Thu 1/1/2026 1:54 PM, highcrew wrote:
> 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.
Once again, one equivalent definition of undefined behavior is: "The
compiler is free to assume that conditions that lead to undefined
behavior never occur".
(And, as a corollary: if some stretch of code is always undefined,
regardless of external conditions, the compiler is free to assume that
the code is never executed.)
The above is exactly how undefined behavior is used for optimizing code
through static analysis.
On your case undefined behavior happens when `i` reaches 4. Hence the
compiler is free to assume that `i` is guaranteed to never reach 4. This
means that the `if` condition is guaranteed to become true at some lower
value of `i` (i.e. the compiler is free to assume that the calling code
made a promise to never pass a `v` that is not present in `table`). This
immediately means that the function will always return 1.
That's what you are observing.
> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
That's is true, but that is a very broad and general formalism. The
logic the compiler follows is not that broad or general. It is
significantly more focused on the properties of the actual code. The
compiler "deduces" the result as I described above.
--
Best regards,
Andrey
[toc] | [prev] | [next] | [standalone]
| From | highcrew <high.crew3868@fastmail.com> |
|---|---|
| Date | 2026-01-04 00:15 +0100 |
| Message-ID | <10jc7v4$1j15f$2@dont-email.me> |
| In reply to | #396112 |
On 1/3/26 4:53 PM, Andrey Tarasevich wrote:
> On your case undefined behavior happens when `i` reaches 4. Hence the
> compiler is free to assume that `i` is guaranteed to never reach 4. This
> means that the `if` condition is guaranteed to become true at some lower
> value of `i` (i.e. the compiler is free to assume that the calling code
> made a promise to never pass a `v` that is not present in `table`). This
> immediately means that the function will always return 1.
OK, I totally have missed that there was a rational justification
for `return 1`! Now I see that `return 1` is actually correct, and
I'm quite surprised. Thank you for pointing it out!
(turns out the compiler is in DENIAL of UB :P)
Interestingly, if I keep in mind this standpoint, every single
UB listed in https://en.cppreference.com/w/c/language/behavior.html
starts to make a lot of sense. I can even *foresee* the
behavior before reading it on the webpage! Damn, I think
something clicked in my head now...
* Signed overflow? UB *can't happen*, therefore `x + 1 > x` is always
true
* Access out of bounds, ...discussed above.
* Uninitialized scalar:
size_t f(int x)
{
size_t a;
if (x) // either x nonzero or UB
a = 42;
return a;
}
Here we *deny* the variable can be used uninitialized,
so the presence of UB implies that x is non-zero.
The function definitely returns 42
* Uninitialized scalar 2:
_Bool p; // uninitialized local variable
if (p) // UB access to uninitialized scalar
puts("p is true");
if (!p) // UB access to uninitialized scalar
puts("p is false");
This is hard to tell ...Shrödinger boolean?
According to the webpage the program might print both
"p is true" and "p is false". Could it be because
the compiler has no choice but take the UB route?
There's no way to mark UB as not reachable.
Fortunately the compiler will usually warn me about
uninitialized variables.
I can see a few bold cases down the line, e.g. "Access to
pointer passed to realloc" where I start wondering if
I could even predict as a human that a certain pointer
passed through realloc.
I have a horrible question now, but that's for a
separate question...
Conclusion: the original UB I've been asking about is
not even a bug. It is the compiler dodging a conditional.
--
High Crew
[toc] | [prev] | [next] | [standalone]
| From | highcrew <high.crew3868@fastmail.com> |
|---|---|
| Date | 2026-01-04 00:25 +0100 |
| Subject | NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jc8gj$1j15f$4@dont-email.me> |
| In reply to | #396125 |
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. -- High Crew
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-03 18:59 -0500 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jcahg$1ijev$1@dont-email.me> |
| In reply to | #396127 |
On 2026-01-03 18: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. Actually, that's not necessarily true. A null pointer is not required to refer to the location with an address of 0. An integer constant expression with a value of 0, converted to a pointer type, is guaranteed to be a null pointer, but that pointer need not have a representation that has all bits 0. However, an integer expression that is not a constant expression, if converted to a pointer type, is not required to be a null pointer - it could convert to an entirely different pointer value. So an implementation could allow it simply by reserving a pointer to some other location (such as the last position in memory) as the representation of a null pointer. > How do I? Even on an implementation that uses a pointer representing a machine address of 0 as a null pointer, such code can still work. In the C standard, "undefined behavior" means that the C standard imposes no requirements on the behavior. That doesn't prohibit other sources from imposing requirements. On such a system, it could define the behavior as accessing the flash.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-04 15:51 +0000 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <o0w6R.1726383$Bg93.576212@fx16.iad> |
| In reply to | #396129 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: >On 2026-01-03 18: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. > >Actually, that's not necessarily true. A null pointer is not required to >refer to the location with an address of 0. An integer constant >expression with a value of 0, converted to a pointer type, is guaranteed >to be a null pointer, but that pointer need not have a representation >that has all bits 0. However, an integer expression that is not a >constant expression, if converted to a pointer type, is not required to >be a null pointer - it could convert to an entirely different pointer value. > >So an implementation could allow it simply by reserving a pointer to >some other location (such as the last position in memory) as the >representation of a null pointer. > >> How do I? > >Even on an implementation that uses a pointer representing a machine >address of 0 as a null pointer, such code can still work. In the C >standard, "undefined behavior" means that the C standard imposes no >requirements on the behavior. That doesn't prohibit other sources from >imposing requirements. On such a system, it could define the behavior as >accessing the flash. Indeed, every C compiler I've ever used has simply dereferenced a pointer that has a value of zero. In user mode, the kernel will generally trap and generate a SIGSEGV or equivalent. In kernel mode, it will just work, assuming that the CPU is configured to run with MMU disabled (or the MMU has a valid mapping for virtual address zero).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-05 08:55 +0100 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jfqqa$2l1be$2@dont-email.me> |
| In reply to | #396143 |
On 04/01/2026 16:51, Scott Lurndal wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 2026-01-03 18: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. >> >> Actually, that's not necessarily true. A null pointer is not required to >> refer to the location with an address of 0. An integer constant >> expression with a value of 0, converted to a pointer type, is guaranteed >> to be a null pointer, but that pointer need not have a representation >> that has all bits 0. However, an integer expression that is not a >> constant expression, if converted to a pointer type, is not required to >> be a null pointer - it could convert to an entirely different pointer value. >> >> So an implementation could allow it simply by reserving a pointer to >> some other location (such as the last position in memory) as the >> representation of a null pointer. >> >>> How do I? >> >> Even on an implementation that uses a pointer representing a machine >> address of 0 as a null pointer, such code can still work. In the C >> standard, "undefined behavior" means that the C standard imposes no >> requirements on the behavior. That doesn't prohibit other sources from >> imposing requirements. On such a system, it could define the behavior as >> accessing the flash. > > Indeed, every C compiler I've ever used has simply dereferenced a > pointer that has a value of zero. In user mode, the kernel will > generally trap and generate a SIGSEGV or equivalent. In kernel > mode, it will just work, assuming that the CPU is configured to > run with MMU disabled (or the MMU has a valid mapping for virtual > address zero). > The context (embedded systems with flash at address 0) implies you don't have signals, an MMU, or other "big OS" features. While embedded systems over a certain size usually have some kind of memory protection unit, and interrupts/traps/exceptions for address or bus errors, you can be very confident that these will not trigger on attempts to read from address 0 if that is part of the normal code address area - the protection systems are not that fine-grained. (You might, while trying to catch a bad pointer bug, put a read watchpoint at address 0 in your debugger.)
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-01-03 17:24 -0800 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jcfh6$1lr6o$1@dont-email.me> |
| In reply to | #396127 |
On Sat 1/3/2026 3:25 PM, 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? Well, the first question would be: what is the physical null pointer representation in that C implementation on that embedded system? Null pointer in C is represented by an integer constant `0` at source code level only (!). The actual physical representation in the compiled code is not necessarily "address 0", contrary to popular misguided belief. It can be anything. It is typically supposed to be chosen as some appropriate "invalid address value" on the given platform. The compiler on that embedded system is, of course, aware of the fact that address 0x00000000 is perfectly valid and should be left accessible. So, for that reason, the compiler is supposed to choose some other physical representation for null pointers, like, say, address 0xFFFFFFFF (just for one example). So, every time you write something like int *p = 0; the compiler will emit code that stores `0xFFFFFFFF` into `p`. In than implementation you will have no problem accessing address 0x00000000. No UB. No problem. But if even under such circumstances the compiler decided to use address 0x00000000 for physically representing null pointers (say, for some other important reasons)... well, then I guess the compiler will have no other choice but to extend the formal language specification and postulate that null pointer access is well-defined. There will be no optimizations based on UB associated with null pointer access. At least in some circumstances. That all would become implementation-defined, of course. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-04 02:19 +0000 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jcio6$1mtsm$1@dont-email.me> |
| In reply to | #396133 |
On Sat, 3 Jan 2026 17:24:54 -0800, Andrey Tarasevich wrote: > The compiler on that embedded system is, of course, aware of the > fact that address 0x00000000 is perfectly valid and should be left > accessible. So, for that reason, the compiler is supposed to choose > some other physical representation for null pointers ... What if the entire machine address space is valid? Are C pointer types supposed to add an extra “invalid” value on top of that?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-03 21:31 -0500 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jcjdo$1n1tp$1@dont-email.me> |
| In reply to | #396134 |
On 2026-01-03 21:19, Lawrence D’Oliveiro wrote: > On Sat, 3 Jan 2026 17:24:54 -0800, Andrey Tarasevich wrote: > >> The compiler on that embedded system is, of course, aware of the >> fact that address 0x00000000 is perfectly valid and should be left >> accessible. So, for that reason, the compiler is supposed to choose >> some other physical representation for null pointers ... > > What if the entire machine address space is valid? Are C pointer types > supposed to add an extra “invalid” value on top of that? Either that, or set aside one piece of addressable memory that is not available to user code. Note, in particular, that it might be a piece of memory used by the implementation of C, or by the operating system. In which case, the undefined behavior that can occur as a result of dereferencing a null point would take the form of messing up the C runtime or the operating system.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-04 04:52 +0000 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jcrm8$1ovmg$1@dont-email.me> |
| In reply to | #396135 |
On Sat, 3 Jan 2026 21:31:20 -0500, James Kuyper wrote: > On 2026-01-03 21:19, Lawrence D’Oliveiro wrote: >> >> What if the entire machine address space is valid? Are C pointer >> types supposed to add an extra “invalid” value on top of that? > > Either that, or set aside one piece of addressable memory that is > not available to user code. Note, in particular, that it might be a > piece of memory used by the implementation of C, or by the operating > system. In which case, the undefined behavior that can occur as a > result of dereferencing a null point would take the form of messing > up the C runtime or the operating system. “Undefined behaviour” could also include “performing a valid memory access”, could it not.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-04 13:00 -0500 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10je9r2$26t30$1@dont-email.me> |
| In reply to | #396137 |
On 2026-01-03 23:52, Lawrence D’Oliveiro wrote: > On Sat, 3 Jan 2026 21:31:20 -0500, James Kuyper wrote: > >> On 2026-01-03 21:19, Lawrence D’Oliveiro wrote: >>> >>> What if the entire machine address space is valid? Are C pointer >>> types supposed to add an extra “invalid” value on top of that? >> >> Either that, or set aside one piece of addressable memory that is >> not available to user code. Note, in particular, that it might be a >> piece of memory used by the implementation of C, or by the operating >> system. In which case, the undefined behavior that can occur as a >> result of dereferencing a null point would take the form of messing >> up the C runtime or the operating system. > > “Undefined behaviour” could also include “performing a valid memory > access”, could it not. Of course. In fact, the single most dangerous thing that can occur when code with undefined behavior is executed is that it does exactly what you incorrectly believe it is required to do. As a result, you fail to be warned of the error in your beliefs.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-04 21:22 +0000 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jelnh$2apo7$5@dont-email.me> |
| In reply to | #396146 |
On Sun, 4 Jan 2026 13:00:02 -0500, James Kuyper wrote: > On 2026-01-03 23:52, Lawrence D’Oliveiro wrote: >> >> On Sat, 3 Jan 2026 21:31:20 -0500, James Kuyper wrote: >> >>> On 2026-01-03 21:19, Lawrence D’Oliveiro wrote: >>>> >>>> What if the entire machine address space is valid? Are C pointer >>>> types supposed to add an extra “invalid” value on top of that? >>> >>> Either that, or set aside one piece of addressable memory that is >>> not available to user code. Note, in particular, that it might be >>> a piece of memory used by the implementation of C, or by the >>> operating system. In which case, the undefined behavior that can >>> occur as a result of dereferencing a null point would take the >>> form of messing up the C runtime or the operating system. >> >> “Undefined behaviour” could also include “performing a valid memory >> access”, could it not. > > Of course. In fact, the single most dangerous thing that can occur > when code with undefined behavior is executed is that it does > exactly what you incorrectly believe it is required to do. As a > result, you fail to be warned of the error in your beliefs. In this case, it’s not clear what choice you have. Call it a C language limitation ...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-04 16:53 -0500 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jengc$26t2v$1@dont-email.me> |
| In reply to | #396147 |
On 2026-01-04 16:22, Lawrence D’Oliveiro wrote: > On Sun, 4 Jan 2026 13:00:02 -0500, James Kuyper wrote: > >> On 2026-01-03 23:52, Lawrence D’Oliveiro wrote: ... >>> “Undefined behaviour” could also include “performing a valid memory >>> access”, could it not. >> >> Of course. In fact, the single most dangerous thing that can occur >> when code with undefined behavior is executed is that it does >> exactly what you incorrectly believe it is required to do. As a >> result, you fail to be warned of the error in your beliefs. > > In this case, it’s not clear what choice you have. I may have lost the thread here - which choice are you talking about?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-05 00:16 +0000 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jevs6$2e9ua$1@dont-email.me> |
| In reply to | #396149 |
On Sun, 4 Jan 2026 16:53:16 -0500, James Kuyper wrote: > On 2026-01-04 16:22, Lawrence D’Oliveiro wrote: >> >> On Sun, 4 Jan 2026 13:00:02 -0500, James Kuyper wrote: >> >>> On 2026-01-03 23:52, Lawrence D’Oliveiro wrote: > ... >>>> “Undefined behaviour” could also include “performing a valid >>>> memory access”, could it not. >>> >>> Of course. In fact, the single most dangerous thing that can occur >>> when code with undefined behavior is executed is that it does >>> exactly what you incorrectly believe it is required to do. As a >>> result, you fail to be warned of the error in your beliefs. >> >> In this case, it’s not clear what choice you have. > > I may have lost the thread here - which choice are you talking > about? What if the entire machine address space is valid? Are C pointer types supposed to add an extra “invalid” value on top of that?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-05 06:41 -0500 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jg80p$26t30$2@dont-email.me> |
| In reply to | #396151 |
On 2026-01-04 19:16, Lawrence D’Oliveiro wrote: > On Sun, 4 Jan 2026 16:53:16 -0500, James Kuyper wrote: > >> On 2026-01-04 16:22, Lawrence D’Oliveiro wrote: ... >>> In this case, it’s not clear what choice you have. >> >> I may have lost the thread here - which choice are you talking >> about? > > What if the entire machine address space is valid? Are C pointer types > supposed to add an extra “invalid” value on top of that? An implementation of C (keep in mind that the implementation includes the compiler, the linker, and the C standard library) can use any location they want for a null pointer, just so long as they make sure that no C object accessible to the user is stored in that location. No user-defined object should be allocated in that location, and no pointer returned by any standard library function (such as malloc() or asctime()) can return that location. If memory is tight, the implementation may use that location to store anything that is never supposed to be accessible to the user. Alternatively, pointers can be larger than needed to store just a machine address, and at least one bit of the extra space can be reserved to identify the pointer as null.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-05 09:07 +0100 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <10jfrfk$2l1be$3@dont-email.me> |
| In reply to | #396146 |
On 04/01/2026 19:00, James Kuyper wrote: > On 2026-01-03 23:52, Lawrence D’Oliveiro wrote: >> On Sat, 3 Jan 2026 21:31:20 -0500, James Kuyper wrote: >> >>> On 2026-01-03 21:19, Lawrence D’Oliveiro wrote: >>>> >>>> What if the entire machine address space is valid? Are C pointer >>>> types supposed to add an extra “invalid” value on top of that? >>> >>> Either that, or set aside one piece of addressable memory that is >>> not available to user code. Note, in particular, that it might be a >>> piece of memory used by the implementation of C, or by the operating >>> system. In which case, the undefined behavior that can occur as a >>> result of dereferencing a null point would take the form of messing >>> up the C runtime or the operating system. >> >> “Undefined behaviour” could also include “performing a valid memory >> access”, could it not. > > Of course. In fact, the single most dangerous thing that can occur when > code with undefined behavior is executed is that it does exactly what > you incorrectly believe it is required to do. As a result, you fail to > be warned of the error in your beliefs. I don't think that is the most dangerous thing that could happen with UB. Code that works as you expected during testing but fails after deployment is much worse. If the UB always results in the effect you intended, then the generated object code is correct for the tasks - even if the source code is unknowingly non-portable. And sometimes - especially in low-level embedded programming - getting the effect you want with the efficiency you want means knowingly writing code that has UB as far as C is concerned, but which results in the desired object code. Such code is inherently non-portable, but so is a lot of low-level embedded code. And you need to check the generated object code carefully, document it well, comment it well, and add any compile-time checks you can for compiler versions and other protection against someone re-using the code later without due consideration.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-04 15:56 +0000 |
| Subject | Re: NULL dereference in embedded [was: On Undefined Behavior] |
| Message-ID | <E4w6R.1726384$Bg93.234775@fx16.iad> |
| In reply to | #396134 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >On Sat, 3 Jan 2026 17:24:54 -0800, Andrey Tarasevich wrote: > >> The compiler on that embedded system is, of course, aware of the >> fact that address 0x00000000 is perfectly valid and should be left >> accessible. So, for that reason, the compiler is supposed to choose >> some other physical representation for null pointers ... > >What if the entire machine address space is valid? Are C pointer types >supposed to add an extra “invalid” value on top of that? In the Burroughs medium systems line, which is (was) a BCD machine addressed to the nibble, the bit pattern for a NULL pointer included 'undigits' (invalid BCD digits 0b1010 through 0b1111). Specifically, @CxEEEEEE@ was the bit pattern for a NULL pointer on that architecture. In 40 years of OS, Hypervisor and firmware programming, I've never seen a C compiler that didn't dereference a NULL pointer when asked to on any modern CPU (x86, 88100, SPARC, MIPS, arm32, arm64).
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web