KK> This doesn't:

KK> int fred(void)
KK> {
KK> while (1) {

KK> }
KK> }

KK> The previous one will be a nuisance diagnosic since the always_true
KK> function always returns true.

KK> If the belief is correct, why not restructure the code:

KK> int fred(void)
KK> {
KK> extern int always_true(void);

KK> for (;;) {
KK> always_true(); // call for its side effect only

KK> }
KK> }

I may be reading this wrong, but aren't you getting into the Halting Problem at
this point?

---------------
user <candycane> is generated from /dev/urandom

.... Discover the recipes you are using and abandon them
___ MultiMail/Linux v0.52

On 9/5/23 11:53 PM, candycane wrote:
> KK> This doesn't:
>
> KK> int fred(void)
> KK> {
> KK> while (1) {
>
> KK> }
> KK> }
>
> KK> The previous one will be a nuisance diagnosic since the always_true
> KK> function always returns true.
>
> KK> If the belief is correct, why not restructure the code:
>
> KK> int fred(void)
> KK> {
> KK> extern int always_true(void);
>
> KK> for (;;) {
> KK> always_true(); // call for its side effect only
>
> KK> }
> KK> }
>
> I may be reading this wrong, but aren't you getting into the Halting Problem at
> this point?
>

Fulling solving the problem would be the Halting Problem, but there are
shortcuts that can get the vast majority.

Mark functions that don't ever return with -Noreturn or [[noreturn]] (or
an equivalent).

Assume loops with a non-constant control expression will at some point
terminate (yes, this isn't strictly true, but is a reasonable
assumption, and is made elsewhere in the standard).

Since the above program has a for loop with an always true condition,
that can be assumed never to end (since there is no "break" in the loop).

Richard Damon <Richard@Damon-Family.org> writes:
> On 9/5/23 11:53 PM, candycane wrote:
>> KK> This doesn't:
>> KK> int fred(void)
>> KK> {
>> KK> while (1) {
>> KK> }
>> KK> }
>> KK> The previous one will be a nuisance diagnosic since the
>> always_true
>> KK> function always returns true.
>> KK> If the belief is correct, why not restructure the code:
>> KK> int fred(void)
>> KK> {
>> KK> extern int always_true(void);
>> KK> for (;;) {
>> KK> always_true(); // call for its side effect only
>> KK> }
>> KK> }
>> I may be reading this wrong, but aren't you getting into the Halting
>> Problem at this point?
>
> Fulling solving the problem would be the Halting Problem, but there
> are shortcuts that can get the vast majority.
>
> Mark functions that don't ever return with -Noreturn or [[noreturn]]
> (or an equivalent).
>
> Assume loops with a non-constant control expression will at some point
> terminate (yes, this isn't strictly true, but is a reasonable
> assumption, and is made elsewhere in the standard).
>
> Since the above program has a for loop with an always true condition,
> that can be assumed never to end (since there is no "break" in the
> loop).

It's not necessary to assume that such loops always terminate. Just
don't assume anything one way or the other.

For example:

int fred(void) {
while (1) {
;
}
}

Since the condition is a constant expression, a reasonably clever
compiler can prove that the closing } is unreachable, so no warning is
necessary. But:

int barney(void) {
while (some_function()) {
;
}
}

Since the condition is not constant, the compiler doesn't know whether
the closing } is reachable. If, as I've suggested, C were to adopt the
C# rules, a diagnostic message would be mandatory, because the closing }
*might* be reached. (Even if the compiler is able to determine that
some_function() always returns 1, because it's defined in the same
translation unit, the diagnostic message would still be required.)

In other words, define a straightforward set of rules for determining
whether a point in the code (particularly the closing } of a non-void
function other than main) is potentially reachable, rules that do not
make any assumptions about non-constant values.

Such a change to C would break some existing code. That's absolutely a
valid reason to oppose it. On the other hand, every major edition of
the C standard has broken some existing code, and compilers have always
supported older versions and/or used non-fatal warnings, so such code
would not be *fatally* broken.

With the C# rules, there are some unavoidable false positives, such as:

int sign(int n) {
if (n < 0) return -1;
if (n == 0) return 0;
if (n > 0) return 1;
}

which are fairly easy to "fix". There are, if I'm not mistaken, no
false negatives.

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

On 9/7/23 4:33 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 9/5/23 11:53 PM, candycane wrote:
>>> KK> This doesn't:
>>> KK> int fred(void)
>>> KK> {
>>> KK> while (1) {
>>> KK> }
>>> KK> }
>>> KK> The previous one will be a nuisance diagnosic since the
>>> always_true
>>> KK> function always returns true.
>>> KK> If the belief is correct, why not restructure the code:
>>> KK> int fred(void)
>>> KK> {
>>> KK> extern int always_true(void);
>>> KK> for (;;) {
>>> KK> always_true(); // call for its side effect only
>>> KK> }
>>> KK> }
>>> I may be reading this wrong, but aren't you getting into the Halting
>>> Problem at this point?
>>
>> Fulling solving the problem would be the Halting Problem, but there
>> are shortcuts that can get the vast majority.
>>
>> Mark functions that don't ever return with -Noreturn or [[noreturn]]
>> (or an equivalent).
>>
>> Assume loops with a non-constant control expression will at some point
>> terminate (yes, this isn't strictly true, but is a reasonable
>> assumption, and is made elsewhere in the standard).
>>
>> Since the above program has a for loop with an always true condition,
>> that can be assumed never to end (since there is no "break" in the
>> loop).
>
> It's not necessary to assume that such loops always terminate. Just
> don't assume anything one way or the other.

Except that if you want to make falling off the end of an non-void
function an error, you can't do that.

Note, from 6.8.5 p6 which states (using N2596):

An iteration statement may be assumed by the implementation to terminate
if its controlling expression is not a constant expression,171) and none
of the following operations are performed in its body, controlling
expression or (in the case of a for statement) its expression-3:172)
— input/output operations
— accessing a volatile object
— synchronization or atomic operations.

This is a rule that allows optimizations to remove a loop that has no
external effect. A similar rule could be used to determine if the end of
the function is potentially reachable.

>
> For example:
>
> int fred(void) {
> while (1) {
> ;
> }
> }
>
> Since the condition is a constant expression, a reasonably clever
> compiler can prove that the closing } is unreachable, so no warning is
> necessary. But:
>
> int barney(void) {
> while (some_function()) {
> ;
> }
> }
>
> Since the condition is not constant, the compiler doesn't know whether
> the closing } is reachable. If, as I've suggested, C were to adopt the
> C# rules, a diagnostic message would be mandatory, because the closing }
> *might* be reached. (Even if the compiler is able to determine that
> some_function() always returns 1, because it's defined in the same
> translation unit, the diagnostic message would still be required.)

Right, because we need to define the level of effort the compiler needs
to do. And it should avoid "surprizes" as much as possible.

>
> In other words, define a straightforward set of rules for determining
> whether a point in the code (particularly the closing } of a non-void
> function other than main) is potentially reachable, rules that do not
> make any assumptions about non-constant values.
>

Right, and using the existing "rule" about loops with non-constant
control expressions makes the most sense.

> Such a change to C would break some existing code. That's absolutely a
> valid reason to oppose it. On the other hand, every major edition of
> the C standard has broken some existing code, and compilers have always
> supported older versions and/or used non-fatal warnings, so such code
> would not be *fatally* broken.
>
> With the C# rules, there are some unavoidable false positives, such as:
>
> int sign(int n) {
> if (n < 0) return -1;
> if (n == 0) return 0;
> if (n > 0) return 1;
> }
>
> which are fairly easy to "fix". There are, if I'm not mistaken, no
> false negatives.
>

Right. But make the function take a double instead of an int, and it CAN
fall through (on some implementations) since there exist double values
that are none of >0, <0 or == 0.

One option would be to allow an [[unreachable]] attribute to mark that
you can't get here, even if the base rules don't prove it, and leave the
results Undefined if you somehow do get there.

Richard Damon <Richard@Damon-Family.org> writes:
> On 9/7/23 4:33 PM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 9/5/23 11:53 PM, candycane wrote:
>>>> KK> This doesn't:
>>>> KK> int fred(void)
>>>> KK> {
>>>> KK> while (1) {
>>>> KK> }
>>>> KK> }
>>>> KK> The previous one will be a nuisance diagnosic since the
>>>> always_true
>>>> KK> function always returns true.
>>>> KK> If the belief is correct, why not restructure the code:
>>>> KK> int fred(void)
>>>> KK> {
>>>> KK> extern int always_true(void);
>>>> KK> for (;;) {
>>>> KK> always_true(); // call for its side effect only
>>>> KK> }
>>>> KK> }
>>>> I may be reading this wrong, but aren't you getting into the Halting
>>>> Problem at this point?
>>>
>>> Fulling solving the problem would be the Halting Problem, but there
>>> are shortcuts that can get the vast majority.
>>>
>>> Mark functions that don't ever return with -Noreturn or [[noreturn]]
>>> (or an equivalent).
>>>
>>> Assume loops with a non-constant control expression will at some point
>>> terminate (yes, this isn't strictly true, but is a reasonable
>>> assumption, and is made elsewhere in the standard).
>>>
>>> Since the above program has a for loop with an always true condition,
>>> that can be assumed never to end (since there is no "break" in the
>>> loop).
>> It's not necessary to assume that such loops always terminate. Just
>> don't assume anything one way or the other.
>
> Except that if you want to make falling off the end of an non-void
> function an error, you can't do that.
>
> Note, from 6.8.5 p6 which states (using N2596):
>
> An iteration statement may be assumed by the implementation to
> terminate if its controlling expression is not a constant
> expression,171) and none of the following operations are performed in
> its body, controlling expression or (in the case of a for statement)
> its expression-3:172)
> — input/output operations
> — accessing a volatile object
> — synchronization or atomic operations.
>
> This is a rule that allows optimizations to remove a loop that has no
> external effect. A similar rule could be used to determine if the end
> of the function is potentially reachable.

That does complicate things. Note that currently an implementation is
allowed but not required to "assume" that the loop terminates.
Currently, the standard never requires control flow analysis to
determine whether a constraint is violated.

I'm not sure what the best solution is. I'd like to say that 6.8.5p6
should be ignored when determining whether a diagnostic is required for
potentially reaching a closing }.

Full disclosure: I really dislike that statement in the standard, both
because of its semantics and because it's written to permit an
implementation to "assume" certain things rather than in terms of
permitted behavior.

>> For example:
>> int fred(void) {
>> while (1) {
>> ;
>> }
>> }
>> Since the condition is a constant expression, a reasonably clever
>> compiler can prove that the closing } is unreachable, so no warning is
>> necessary. But:
>> int barney(void) {
>> while (some_function()) {
>> ;
>> }
>> }
>> Since the condition is not constant, the compiler doesn't know
>> whether
>> the closing } is reachable. If, as I've suggested, C were to adopt the
>> C# rules, a diagnostic message would be mandatory, because the closing }
>> *might* be reached. (Even if the compiler is able to determine that
>> some_function() always returns 1, because it's defined in the same
>> translation unit, the diagnostic message would still be required.)
>
> Right, because we need to define the level of effort the compiler
> needs to do. And it should avoid "surprizes" as much as possible.
>
>> In other words, define a straightforward set of rules for
>> determining
>> whether a point in the code (particularly the closing } of a non-void
>> function other than main) is potentially reachable, rules that do not
>> make any assumptions about non-constant values.
>>
>
> Right, and using the existing "rule" about loops with non-constant
> control expressions makes the most sense.
>
>> Such a change to C would break some existing code. That's absolutely a
>> valid reason to oppose it. On the other hand, every major edition of
>> the C standard has broken some existing code, and compilers have always
>> supported older versions and/or used non-fatal warnings, so such code
>> would not be *fatally* broken.
>> With the C# rules, there are some unavoidable false positives, such
>> as:
>> int sign(int n) {
>> if (n < 0) return -1;
>> if (n == 0) return 0;
>> if (n > 0) return 1;
>> }
>> which are fairly easy to "fix". There are, if I'm not mistaken, no
>> false negatives.
>
> Right. But make the function take a double instead of an int, and it
> CAN fall through (on some implementations) since there exist double
> values that are none of >0, <0 or == 0.

That's a different function. I wrote the sign() function above to make
the point I wanted to make.

> One option would be to allow an [[unreachable]] attribute to mark that
> you can't get here, even if the base rules don't prove it, and leave
> the results Undefined if you somehow do get there.

I like it. It's similar to the /*NOTREACHED*/ comment recognized by
many lint implementations.

It could be added *instead* of requiring reachability analysis, and a
programmer could add [[unreachable]] before the closing } of a non-void
function. But adding the requirement I propose would catch errors made
by programmers who don't do that.

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

On 2023-09-08, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> Note, from 6.8.5 p6 which states (using N2596):
>>
>> An iteration statement may be assumed by the implementation to
>> terminate if its controlling expression is not a constant
>> expression,171) and none of the following operations are performed in
>> its body, controlling expression or (in the case of a for statement)
>> its expression-3:172)
>> — input/output operations
>> — accessing a volatile object
>> — synchronization or atomic operations.
>>
>> This is a rule that allows optimizations to remove a loop that has no
>> external effect. A similar rule could be used to determine if the end
>> of the function is potentially reachable.
>
> That does complicate things. Note that currently an implementation is
> allowed but not required to "assume" that the loop terminates.
> Currently, the standard never requires control flow analysis to
> determine whether a constraint is violated.

I don't understand the problem. For diagnosing suspected situations
of the end of the function being reached, we want to assume as much
as possible that loops terminate, unless it's obvious otherwise.

Since the above allows the implementation to assume that a loop with
a non-constant controlling expression, and certain other attributes,
terminates, that is compatible; it's what you would want to assume
about that loop when looking whether to apply the diagnostic.

If such a loop precedes the end of the function, and is diagnosed
under a constraint rule, it doesn't matter that it's also optimized
away.

>> One option would be to allow an [[unreachable]] attribute to mark that
>> you can't get here, even if the base rules don't prove it, and leave
>> the results Undefined if you somehow do get there.
>
> I like it. It's similar to the /*NOTREACHED*/ comment recognized by
> many lint implementations.
>
> It could be added *instead* of requiring reachability analysis, and a
> programmer could add [[unreachable]] before the closing } of a non-void
> function. But adding the requirement I propose would catch errors made
> by programmers who don't do that.

The problem with unreachable is that it's a double edged sword.
Here we are thinking of how it helps with diagnosis.

However, it will end up defined as a statement whose purpose is to
invoke undefined behavior. I.e. if [[unreachable]] is reached,
the behavior is undefined, and that's how it works. The assumption
that the program is free of undefined behavior means that no
[[unreachable]] is reached.

Today, an abort() call serves as an expected unreachable point
which has a defined behavior.

If [[unreachable]] were defined as requiring a run-time diagnostic
and termination if it is reached, rather than invoking UB, it would be
more or less the same as abort(); little point in adding it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 08/09/2023 07:16, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:

>> One option would be to allow an [[unreachable]] attribute to mark that
>> you can't get here, even if the base rules don't prove it, and leave
>> the results Undefined if you somehow do get there.
>
> I like it. It's similar to the /*NOTREACHED*/ comment recognized by
> many lint implementations.
>

Even better, IMHO, would be a clearly named function (or function-like
macro) to indicate unreachable code. Fortunately for me, C23 has
already thought of that!

<https://en.cppreference.com/w/c/program/unreachable>

Until C23 comes out, many of us can use "__builtin_unreachable()" in
gcc, clang, icc, etc., or "__assume(false))" in MSVC.

> It could be added *instead* of requiring reachability analysis, and a
> programmer could add [[unreachable]] before the closing } of a non-void
> function. But adding the requirement I propose would catch errors made
> by programmers who don't do that.
>

Why not have both? Each solution is useful in situations where the
other is not.

On 08/09/2023 09:09, Kaz Kylheku wrote:

> The problem with unreachable is that it's a double edged sword.
> Here we are thinking of how it helps with diagnosis.

Many features of C are double-edged swords.

(This has always struck me as a silly idiom in English, given that for
straight swords, a double blade is almost invariably a good thing. I
think the idiom came from "a sword cuts both ways", which is a much more
rational idiom.)

"Unreachable" indicators have been common in C programming for a very
long time, especially in code that needs to be efficient. And they are
used internally in C compilers more often - gcc and clang generate the
same internal representation for "__builtin_unreachable()" as they do
for code paths that result from undefined behaviour.

>
> However, it will end up defined as a statement whose purpose is to
> invoke undefined behavior. I.e. if [[unreachable]] is reached,
> the behavior is undefined, and that's how it works. The assumption
> that the program is free of undefined behavior means that no
> [[unreachable]] is reached.

Yes.

>
> Today, an abort() call serves as an expected unreachable point
> which has a defined behavior.

True - but an "abort()" call is not free. For small functions (such as
the "sign" function given by Keith a couple of posts up), it would
cripple the code efficiency.

For some code, it could be a good choice. For my own code, in most
cases where I use "__builtin_unreachable()", "abort" would almost
certainly a bad choice.

>
> If [[unreachable]] were defined as requiring a run-time diagnostic
> and termination if it is reached, rather than invoking UB, it would be
> more or less the same as abort(); little point in adding it.
>

Agreed - so it should /not/ be so defined. People who want "abort()"
know where to find it.

Note that since trying to execute "unreachable()" (as the C23 function
is called) is undefined behaviour, compilers can freely add debugging
and fault-finding options to give a run-time diagnostic if the code is
actually reached. But if the standard had defined the behaviour of
"unreachable()" to be somewhat like "abort()", compilers would not be
free to use it for efficient optimisation, or to aid static analysis.

On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>
> Note that since trying to execute "unreachable()" (as the C23 function
> is called) is undefined behaviour, compilers can freely add debugging
> and fault-finding options to give a run-time diagnostic if the code is
> actually reached. But if the standard had defined the behaviour of
> "unreachable()" to be somewhat like "abort()", compilers would not be
> free to use it for efficient optimisation, or to aid static analysis.
>
The difference is that the programmer might want to deliberately call
abort() as part of the expected runtime behaviour of the program. Whilst
unreachable() can only be called if he has made a programming error.
However he might want to fall back to defined behaviour in the case of
such an error.
However compilers can run unreachable code tests which would otherwise
be too expensive if they encounter an unreachable() statement. What
they can't do is use the unreachable() statement as a proof that the
code is in fact unreachable.

On 08/09/2023 10:30, Malcolm McLean wrote:
> On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>
>> Note that since trying to execute "unreachable()" (as the C23 function
>> is called) is undefined behaviour, compilers can freely add debugging
>> and fault-finding options to give a run-time diagnostic if the code is
>> actually reached. But if the standard had defined the behaviour of
>> "unreachable()" to be somewhat like "abort()", compilers would not be
>> free to use it for efficient optimisation, or to aid static analysis.
>>
> The difference is that the programmer might want to deliberately call
> abort() as part of the expected runtime behaviour of the program. Whilst
> unreachable() can only be called if he has made a programming error.
> However he might want to fall back to defined behaviour in the case of
> such an error.

If a programmer wants such behaviour, then he or she should know how to
write it.

> However compilers can run unreachable code tests which would otherwise
> be too expensive if they encounter an unreachable() statement. What
> they can't do is use the unreachable() statement as a proof that the
> code is in fact unreachable.

Compilers can, and do, do exactly that. C is very much a "trust the
programmer" language, not a hand-holding language. If I write
"unreachable();", I expect my compiler to believe me and trust that the
code cannot ever be reached (or that I don't care what happens if it
/is/ reached). I don't want it to add extra code to check if the code
is reached, or to call abort() if it is reached. What I want is for the
compiler to use that extra information to make other code more
efficient, and to allow more compile-time warnings and static error
checking.

That's the deal with C - the compiler believes the programmer, and the
programmer is careful not to lie to the compiler. If you don't like
that, pick a different programming language.

So if you are not sure the code point is unreachable, don't "call"
unreachable(). It's very simple.

On 08/09/2023 10:26, David Brown wrote:
> On 08/09/2023 10:30, Malcolm McLean wrote:
>> On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>>
>>> Note that since trying to execute "unreachable()" (as the C23 function
>>> is called) is undefined behaviour, compilers can freely add debugging
>>> and fault-finding options to give a run-time diagnostic if the code is
>>> actually reached. But if the standard had defined the behaviour of
>>> "unreachable()" to be somewhat like "abort()", compilers would not be
>>> free to use it for efficient optimisation, or to aid static analysis.
>>>
>> The difference is that the programmer might want to deliberately call
>> abort() as part of the expected runtime behaviour of the program. Whilst
>> unreachable() can only be called if he has made a programming error.
>> However he might want to fall back to defined behaviour in the case of
>> such an error.
>
> If a programmer wants such behaviour, then he or she should know how to
> write it.
>
>> However compilers can run unreachable code tests which would otherwise
>> be too expensive if they encounter an unreachable() statement. What
>> they can't do is use the unreachable() statement as a proof that the
>> code is in fact unreachable.
>
> Compilers can, and do, do exactly that.  C is very much a "trust the
> programmer" language, not a hand-holding language.  If I write
> "unreachable();", I expect my compiler to believe me and trust that the
> code cannot ever be reached (or that I don't care what happens if it
> /is/ reached).  I don't want it to add extra code to check if the code
> is reached, or to call abort() if it is reached.  What I want is for the
> compiler to use that extra information to make other code more
> efficient, and to allow more compile-time warnings and static error
> checking.

It's funny that some people don't want the bother of writing 'return 0;'
in a path they know will never be reached, while others are prepared to
write 'unreachable();', which is both longer and uses shifted characters.

If the programmer is wrong however, 'unreachable()' won't stop garbage
(which can include a misleadingly correct result) from being returned.

> That's the deal with C - the compiler believes the programmer, and the
> programmer is careful not to lie to the compiler.  If you don't like
> that, pick a different programming language.

Which one that fixes that one detail and doesn't involve a total rewrite
of your software? And which doesn't introduce a hundred new problems
that are even more of a pain to deal with,

>
> So if you are not sure the code point is unreachable, don't "call"
> unreachable().  It's very simple.
>

On Friday, 8 September 2023 at 10:27:12 UTC+1, David Brown wrote:
> On 08/09/2023 10:30, Malcolm McLean wrote:
> > On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
> >>
> >> Note that since trying to execute "unreachable()" (as the C23 function
> >> is called) is undefined behaviour, compilers can freely add debugging
> >> and fault-finding options to give a run-time diagnostic if the code is
> >> actually reached. But if the standard had defined the behaviour of
> >> "unreachable()" to be somewhat like "abort()", compilers would not be
> >> free to use it for efficient optimisation, or to aid static analysis.
> >>
> > The difference is that the programmer might want to deliberately call
> > abort() as part of the expected runtime behaviour of the program. Whilst
> > unreachable() can only be called if he has made a programming error.
> > However he might want to fall back to defined behaviour in the case of
> > such an error.
> If a programmer wants such behaviour, then he or she should know how to
> write it.
> > However compilers can run unreachable code tests which would otherwise
> > be too expensive if they encounter an unreachable() statement. What
> > they can't do is use the unreachable() statement as a proof that the
> > code is in fact unreachable.
> Compilers can, and do, do exactly that. C is very much a "trust the
> programmer" language, not a hand-holding language. If I write
> "unreachable();", I expect my compiler to believe me and trust that the
> code cannot ever be reached (or that I don't care what happens if it
> /is/ reached). I don't want it to add extra code to check if the code
> is reached, or to call abort() if it is reached. What I want is for the
> compiler to use that extra information to make other code more
> efficient, and to allow more compile-time warnings and static error
> checking.
>
> That's the deal with C - the compiler believes the programmer, and the
> programmer is careful not to lie to the compiler. If you don't like
> that, pick a different programming language.
>
> So if you are not sure the code point is unreachable, don't "call"
> unreachable(). It's very simple.
>
This is a basic misunderstanding you have shown before.

In your world, you should never wear a seatbelt, because if you are at
risk of crashing into the car in front, you shouldn't be driving.
Of course that's nonsense. Experienced driver will occasionally have
moment of inattention. Very rarely, this will produce an accident,
and then the seatbelt is a life saver. Of course most seatbelts are
never used for their intended purpose. But it's still worth having.

Similarly, if you know that code cannot be reached, then unreachable()
can have undefined behaviour. But even experienced programmer make
mistakes. Less so maybe in the sort of programming you do. In
the sort of programming other people do, you often do have termination
conditions which depend on various mathematically proven properties
like convergence being correct. But of course threre could be a subtle
programming error which means that the mathematical property isn't
always met.
So a defined behaviour fallback is potentially useful. "This can't happen,
but if it does, give me this diagnostic".

On 08/09/2023 11:44, Bart wrote:
> On 08/09/2023 10:26, David Brown wrote:
>> On 08/09/2023 10:30, Malcolm McLean wrote:
>>> On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>>>
>>>> Note that since trying to execute "unreachable()" (as the C23 function
>>>> is called) is undefined behaviour, compilers can freely add debugging
>>>> and fault-finding options to give a run-time diagnostic if the code is
>>>> actually reached. But if the standard had defined the behaviour of
>>>> "unreachable()" to be somewhat like "abort()", compilers would not be
>>>> free to use it for efficient optimisation, or to aid static analysis.
>>>>
>>> The difference is that the programmer might want to deliberately call
>>> abort() as part of the expected runtime behaviour of the program. Whilst
>>> unreachable() can only be called if he has made a programming error.
>>> However he might want to fall back to defined behaviour in the case of
>>> such an error.
>>
>> If a programmer wants such behaviour, then he or she should know how
>> to write it.
>>
>>> However compilers can run unreachable code tests which would otherwise
>>> be too expensive if they encounter an unreachable() statement. What
>>> they can't do is use the unreachable() statement as a proof that the
>>> code is in fact unreachable.
>>
>> Compilers can, and do, do exactly that.  C is very much a "trust the
>> programmer" language, not a hand-holding language.  If I write
>> "unreachable();", I expect my compiler to believe me and trust that
>> the code cannot ever be reached (or that I don't care what happens if
>> it /is/ reached).  I don't want it to add extra code to check if the
>> code is reached, or to call abort() if it is reached.  What I want is
>> for the compiler to use that extra information to make other code more
>> efficient, and to allow more compile-time warnings and static error
>> checking.
>
>
> It's funny that some people don't want the bother of writing 'return 0;'
> in a path they know will never be reached, while others are prepared to
> write 'unreachable();', which is both longer and uses shifted characters.
>

Some of us get paid to write good quality, readable and maintainable
software. I suppose there are other programmers who get paid per letter
they type, or are charged per byte of disk space they use, for whom the
number of keystrokes is a relevant metric.

I don't want to write "return 0;" if that line will never be executed,
because it would be misleading and untestable. I /do/ want to write
"unreachable();" because it is clear and precise, giving important
information to both the compiler and readers.

> If the programmer is wrong however, 'unreachable()' won't stop garbage
> (which can include a misleadingly correct result) from being returned.

That is true. But if the programmer is wrong and writes "return 0;" in
the wrong place, things could go equally badly. When programmers write
the wrong thing, bad things may happen - that's inevitable in
programming. One way to minimise the risk of that is by writing code
that makes sense - say what the code does, such as writing
"unreachable();" when you know that line cannot be reached, rather than
writing nonsense such as "return 0;" when the code cannot return from there.

>
>
>> That's the deal with C - the compiler believes the programmer, and the
>> programmer is careful not to lie to the compiler.  If you don't like
>> that, pick a different programming language.
>
> Which one that fixes that one detail and doesn't involve a total rewrite
> of your software?

Which "one detail" are you talking about? Malcolm was complaining that
compilers might believe a programmer that wrote "unreachable();". I
don't consider that to be something that needs fixing, and I don't
consider the general point of compilers trusting the programmer as
either something to fix, or a single detail.

> And which doesn't introduce a hundred new problems
> that are even more of a pain to deal with,

That's not my problem. I don't know of any programming language where
the tools do not trust what the programmer writes or where the
programmer can lie or mislead the compiler with impunity. But if
Malcolm wants to be able to do that, it is up to him to try to find a
language that suits his needs better than C. Maybe something with a
restricted virtual machine would suit him.

I make a point of trying to pick the right language for any given task -
whether it be C (and if so, which standards version, which extensions,
which restrictions, which coding standard, etc.), C++, Python, or
something else. There are often many factors to consider.

>
>>
>> So if you are not sure the code point is unreachable, don't "call"
>> unreachable().  It's very simple.
>>
>

On 08/09/2023 11:47, Malcolm McLean wrote:
> On Friday, 8 September 2023 at 10:27:12 UTC+1, David Brown wrote:
>> On 08/09/2023 10:30, Malcolm McLean wrote:
>>> On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>>>
>>>> Note that since trying to execute "unreachable()" (as the C23 function
>>>> is called) is undefined behaviour, compilers can freely add debugging
>>>> and fault-finding options to give a run-time diagnostic if the code is
>>>> actually reached. But if the standard had defined the behaviour of
>>>> "unreachable()" to be somewhat like "abort()", compilers would not be
>>>> free to use it for efficient optimisation, or to aid static analysis.
>>>>
>>> The difference is that the programmer might want to deliberately call
>>> abort() as part of the expected runtime behaviour of the program. Whilst
>>> unreachable() can only be called if he has made a programming error.
>>> However he might want to fall back to defined behaviour in the case of
>>> such an error.
>> If a programmer wants such behaviour, then he or she should know how to
>> write it.
>>> However compilers can run unreachable code tests which would otherwise
>>> be too expensive if they encounter an unreachable() statement. What
>>> they can't do is use the unreachable() statement as a proof that the
>>> code is in fact unreachable.
>> Compilers can, and do, do exactly that. C is very much a "trust the
>> programmer" language, not a hand-holding language. If I write
>> "unreachable();", I expect my compiler to believe me and trust that the
>> code cannot ever be reached (or that I don't care what happens if it
>> /is/ reached). I don't want it to add extra code to check if the code
>> is reached, or to call abort() if it is reached. What I want is for the
>> compiler to use that extra information to make other code more
>> efficient, and to allow more compile-time warnings and static error
>> checking.
>>
>> That's the deal with C - the compiler believes the programmer, and the
>> programmer is careful not to lie to the compiler. If you don't like
>> that, pick a different programming language.
>>
>> So if you are not sure the code point is unreachable, don't "call"
>> unreachable(). It's very simple.
>>
> This is a basic misunderstanding you have shown before.

No, I am not misunderstanding anything - but I think /you/ are greatly
misunderstanding /me/.

>
> In your world, you should never wear a seatbelt, because if you are at
> risk of crashing into the car in front, you shouldn't be driving.

Not at all - that is not even remotely equivalent. I am surprised that
someone as experience in programming as yourself does not see it
immediately.

The risks when driving are unknowns - other people on the road, icy
patches, kids jumping out in front of the car, etc. Some things you
have partial control over, such as how well you have learned to drive,
others you don't - such as an unexpected sneeze. These are all inputs -
and your code should always check and sanitize input data from unknown
sources.

Compile-time information is about the car and/or driver, not the trip.
You check the seat is in the right position once, before starting, not
every time you want to press a pedal. You trust that the experts do
their job - you don't open up the wheel mountings to see if the brakes
are in order, but trust the mechanic at the workshop. When you turn the
steering wheel, the car's wheels turn - because the car "trusts" that
the driver knows what he or she is doing.

And more relevantly, when writing software, you check the code at many
stages - you check it when writing it, you test it at run-time, you have
other people check it in code reviews, you have your static error
checking software check what it can. You don't whip together a bunch of
code and deploy it on the basis of "it compiles, so it must be right -
any serious issue would have given an error on compilation, not just a
warning." /That/ would be more akin to driving without a seat belt.

So - back to reality and programming. I write "unreachable()" for parts
of the code that I know can never be reached, because that is useful
information to readers and the compiler. I expect the compiler to trust
me, and to make use of that information to optimise the code. That's
the compiler's job - I write in clear, high-level C code, and it turns
that into efficient object code.

If I see someone has written code such as :

abort(); // Can never reach this

I know that something in the development process is broken or
untrustworthy. Perhaps the programmer can't trust the compiler - there
are occasions when people have no choice but to use poor quality tools,
and even the best tools are not bug-free. Perhaps the programmer is
inexperienced, and thinks this is a good idea. Perhaps the warnings
used in the compiler complain if there is nothing there (such as if you
use Bart's compiler in the examples discussed). Perhaps the project
manager is inexperienced, and thinks this is a case of being "doubly
safe". Certainly something is wrong.

> Of course that's nonsense.

Yes, I agree - your analogy was utter nonsense.

>
> Similarly, if you know that code cannot be reached, then unreachable()
> can have undefined behaviour.

No.

We are talking here about run-time undefined behaviour. Since the code
line will never be reached when running the program, there cannot be
undefined behaviour from it (or defined behaviour, for that matter -
there is /no/ behaviour as it does not run).

> But even experienced programmer make
> mistakes. Less so maybe in the sort of programming you do. In
> the sort of programming other people do, you often do have termination
> conditions which depend on various mathematically proven properties
> like convergence being correct. But of course threre could be a subtle
> programming error which means that the mathematical property isn't
> always met.

If there is a possibility of the code reaching that point,
"unreachable()" would not be appropriate.

It's a bit like noting that if you don't want to write some output to
the terminal, writing "printf" is not appropriate.

What is so difficult about writing what you mean when programming?

Sure, programmers make mistakes. That's why you have code reviews, and
testing. That's why you use a debugger, and sanitizers, and other
tools. That's why it is important to write code that you mean, and not
nonsense that you don't mean. And you don't write code that is
untestable such as lines that cannot be reached, or code that makes no
sense to a reviewer claiming to do something in impossible situations.

>
> So a defined behaviour fallback is potentially useful. "This can't happen,
> but if it does, give me this diagnostic".

Where did you learn about logic? From watching Monty Python?

Things that can't happen, can't happen. If the thing /might/ happen,
then it /can/ happen.

Do you think I write my code by guesswork? Do you think I say to
myself, "I guess this is unlikely, and I don't want to consider it -
we'll pretend it it's impossible and tell the compiler its unreachable.
I'm sure no one will notice" ?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>
>> Note that since trying to execute "unreachable()" (as the C23 function
>> is called) is undefined behaviour, compilers can freely add debugging
>> and fault-finding options to give a run-time diagnostic if the code is
>> actually reached. But if the standard had defined the behaviour of
>> "unreachable()" to be somewhat like "abort()", compilers would not be
>> free to use it for efficient optimisation, or to aid static analysis.
>>
>The difference is that the programmer might want to deliberately call
>abort() as part of the expected runtime behaviour of the program.

Not in any company I've worked with. abort() is extremely user-unfriendly.

On Friday, 8 September 2023 at 15:03:51 UTC+1, David Brown wrote:
> On 08/09/2023 11:47, Malcolm McLean wrote:
>
> > So a defined behaviour fallback is potentially useful. "This can't happen,
> > but if it does, give me this diagnostic".
> Where did you learn about logic? From watching Monty Python?
>
> Things that can't happen, can't happen. If the thing /might/ happen,
> then it /can/ happen.
>
> Do you think I write my code by guesswork? Do you think I say to
> myself, "I guess this is unlikely, and I don't want to consider it -
> we'll pretend it it's impossible and tell the compiler its unreachable.
> I'm sure no one will notice" ?
>
OK so

int sign(double x)
{ if (x < 0) return -1;
if (x == 0) retun 0;
if (x > 0) return 1;
/* unreachable */
}

Yes?
No. In David Brown world, no-one would ever make that mistake. In reality,
it's the sort of thing that is quite likely to slip through. In fact sign() needs
to return a double to handle the corner case properly.

It's NaN of course. The sign of NaN is NaN.
Or you could say that NaN isn't in the domain of the function and either catch
it, or just ignore it and accept any garbage - the real bug will be upstream.
Or you could say that the code is unreachable because we always filter
out NaN. But how would you prove that?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> int sign(double x)
> {
> if (x < 0) return -1;
> if (x == 0) retun 0;
> if (x > 0) return 1;
> /* unreachable */
> }

Just for information...

> In fact sign() needs to return a double to handle the corner case properly.
>
> It's NaN of course. The sign of NaN is NaN.

In IEEE floating point (almost universal these days) NaNs (and
infinities) are signed, and the sign often carries useful information.
You can't just state that "the sign of NaN is NaN" as if it's a plain
fact. One might want, for example, something more like:

return x == 0 ? 0 : 1 - 2*signbit(x);

The information alluded to above being that some readers may not know
that C has a signbit macro.

--
Ben.

On Saturday, 9 September 2023 at 01:52:30 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > int sign(double x)
> > {
> > if (x < 0) return -1;
> > if (x == 0) retun 0;
> > if (x > 0) return 1;
> > /* unreachable */
> > }
> Just for information...
> > In fact sign() needs to return a double to handle the corner case properly.
> >
> > It's NaN of course. The sign of NaN is NaN.
> In IEEE floating point (almost universal these days) NaNs (and
> infinities) are signed, and the sign often carries useful information.
> You can't just state that "the sign of NaN is NaN" as if it's a plain
> fact. One might want, for example, something more like:
>
> return x == 0 ? 0 : 1 - 2*signbit(x);
>
> The information alluded to above being that some readers may not know
> that C has a signbit macro.
>
IEEE also allows for signed zero. But the sign of zero is zero. Certainly for
positive zero. I suppose you might argue that for the rare negative zeroes
you should return -1.

On 2023-09-08, Bart <bc@freeuk.com> wrote:
> It's funny that some people don't want the bother of writing 'return 0;'
> in a path they know will never be reached, while others are prepared to
> write 'unreachable();', which is both longer and uses shifted characters.

What is worse, the original program with a missing "return 0;" might
well be correct. If the caller doesn't extract the return value,
everything is copacetic.

Whereas unreachable() is a gizmo whose only meaning is that it invokes
undefined behavior if executed!

It's like you have a pepper shaker on your programing table labeled
"UB", and you sprinkle that on your program.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-08, Scott Lurndal <scott@slp53.sl.home> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>>
>>> Note that since trying to execute "unreachable()" (as the C23 function
>>> is called) is undefined behaviour, compilers can freely add debugging
>>> and fault-finding options to give a run-time diagnostic if the code is
>>> actually reached. But if the standard had defined the behaviour of
>>> "unreachable()" to be somewhat like "abort()", compilers would not be
>>> free to use it for efficient optimisation, or to aid static analysis.
>>>
>>The difference is that the programmer might want to deliberately call
>>abort() as part of the expected runtime behaviour of the program.
>
> Not in any company I've worked with. abort() is extremely user-unfriendly.

It's better than exit. More than once I had to fix a well-meaning
exit(0) or exit(1) in error handling code to abort.

For instance if you have the program under the debugger, abort will
stop and you ahve a call stack.

To get that from exit, you have to put a breakpoint on exit.

abort() can leave core dumps.

If all you do is call abort, it's user unfriendly because there is
no diagnostic. However, the astute Unix graybeard will notice that
the program died due to signal 6. :)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote:
> I don't want to write "return 0;" if that line will never be executed,
> because it would be misleading and untestable.

OK; that's a situation in which you consciously don't want it;
you're not omitting it because you got distracted.

> I /do/ want to write
> "unreachable();" because it is clear and precise, giving important
> information to both the compiler and readers.

But then you have to be sure that this logical fact is true;
since it is an iron-clad assertion, the justification behind it
(which the compiler doesn't see nor care about) has to be iron
clad.

There is a risk in it because it's possible that if you neither
add "return 0" nor "unreachable()" that the situation might not
be erroneous at all if that end is reached.

Whereas with unreachable() that becomes UB.
>
>> If the programmer is wrong however, 'unreachable()' won't stop garbage
>> (which can include a misleadingly correct result) from being returned.
>
> That is true. But if the programmer is wrong and writes "return 0;" in
> the wrong place, things could go equally badly.

Not there though; somewhere farther down the road where the can has
been kicked. But yes.

> When programmers write
> the wrong thing, bad things may happen - that's inevitable in
> programming. One way to minimise the risk of that is by writing code
> that makes sense - say what the code does, such as writing
> "unreachable();" when you know that line cannot be reached, rather than
> writing nonsense such as "return 0;" when the code cannot return from there.

Or abort() when that makes sense; like that it would be bad for that
code to be reached, and we don't think it is, but we are not so
committed to that proposition that we're willing to bet on it with
undefined behavior. And we don't mind the extra instructions for that in
that situation.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote:
> So if you are not sure the code point is unreachable, don't "call"
> unreachable(). It's very simple.

Here is a bit of evening entertainment.

In a Lisp compiler I developed I was suprised to see that it optimized
away the return sequence from a function due to that being unreachable
(not by being declared that way, just deduced trhough control flow
analysis).

Watch what happens to at optimization levels 0, 3 and 5 to the
expression (while t (put-line "hello")), an infinite loop:

I was surprised because I was not "after" that at all; the optimizations were
not developed with that specific situation in mind.

It's a like when people write chess programs which then surprise them
by playing betetr than their makers.

Baseline code geneartion at level zero:

1> (let ((*opt-level* 0)) (disassemble (compile-toplevel '(while t (put-line "hello")))))
data:
0: t
1: "hello"
syms:
0: put-line
code:
0: 4C00000B block t2 nil 11
1: 00020000
2: 04020000 frame 2 0
3: 38000008 if d0 8
4: 00000400
5: 20010005 gcall t5 0 d1
6: 04010000
7: 34000003 jmp 3
8: 10000000 end nil
9: 2C020000 movsr t2 nil
10: 10000002 end t2
11: 10000002 end t2
instruction count:
9
#<sys:vm-desc: 9009a60>

At level 3, the block and frame are removed. However, "if d0 5" is being
stupidly executed. This means branch off to the instruction at offset 5 if the
condition is NOT true, otherwise proceed. d0 refers to a static data register,
which holds the t symbol; the condition is always true.

2> (let ((*opt-level* 3)) (disassemble (compile-toplevel '(while t (put-line "hello")))))
data:
0: t
1: "hello"
syms:
0: put-line
code:
0: 38000005 if d0 5
1: 00000400
2: 20010005 gcall t5 0 d1
3: 04010000
4: 34000000 jmp 0
5: 10000000 end nil
instruction count:
4
#<sys:vm-desc: 90cd530>

At level 5, things get more clever. The pointless if instruction is removed.

The "5 ... end nil" instruction was only reachable through that instruction
taking the branch, and so that instruction is gone:

3> (let ((*opt-level* 5)) (disassemble (compile-toplevel '(while t (put-line "hello")))))
data:
0: "hello"
syms:
0: put-line
code:
0: 20010005 gcall t5 0 d0
1: 04000000
2: 34000000 jmp 0
instruction count:
2
#<sys:vm-desc: 927f610>

So now the function doesn't include a wasteful end instruction.
That stood out to my eyes right away because right until that point I was so
used to seeing those terminating "end" instructions.

In C, a compiler could do something similar: when the end of the function is
not reachable, it could omit emitting any register restoring code and ret
instruction, making the function smaller.

Now if you lie to the compiler that the end is unreachable, even though it is,
it could do the optimization code anyway, and leave the branch in place. Or
remove the branch also, and adjust the jmp so that the loop becomes infinite.

For instance suppose the instruction tested some register t4, which gets
loaded from some global variable that could be changing. that "if t4 5",
in the false case, jumps to code that we have declard unreachable.
There is no point in that, so the instruction gets erased.

Since the instruction gets erased, the instruction which calculated t4
now by accessing the global variable now a dead t4 register.
So that instruction gets removed. The backwards jmp in the loop
now goes to whatever instruction follows: the loop has become infinite;
repeating without testing that global variable.

Wrong facts that you declare trigger a cascade of deductions that are
increasingly removed from the circumstances of that fact.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-09-08, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>On Friday, 8 September 2023 at 09:10:20 UTC+1, David Brown wrote:
>>>>
>>>> Note that since trying to execute "unreachable()" (as the C23 function
>>>> is called) is undefined behaviour, compilers can freely add debugging
>>>> and fault-finding options to give a run-time diagnostic if the code is
>>>> actually reached. But if the standard had defined the behaviour of
>>>> "unreachable()" to be somewhat like "abort()", compilers would not be
>>>> free to use it for efficient optimisation, or to aid static analysis.
>>>>
>>>The difference is that the programmer might want to deliberately call
>>>abort() as part of the expected runtime behaviour of the program.
>>
>> Not in any company I've worked with. abort() is extremely user-unfriendly.
>
>It's better than exit. More than once I had to fix a well-meaning
>exit(0) or exit(1) in error handling code to abort.

I do not disagree with that statement; I did not intend to imply
that simply exit was a proper error handling mechanism.

There are a number of ways to produce useful information in such
a situation if it cannot be recovered from (which should be the
first choice, when possible).

On 09/09/2023 03:57, Kaz Kylheku wrote:
> On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote:
>> I don't want to write "return 0;" if that line will never be executed,
>> because it would be misleading and untestable.
>
> OK; that's a situation in which you consciously don't want it;
> you're not omitting it because you got distracted.

Correct.

A warning (such as gcc has) based on reachability analysis in a compiler
should be able to warn about real missing returns without false
positives about clearly unreachable situations, so there is no need to
add such unhelpful returns. In some situations, the programmer knows
more than the compiler, and the compiler can't prove that the final
close braces is unreachable - that's when it is helpful to write
"unreachable();" explicitly.

>
>> I /do/ want to write
>> "unreachable();" because it is clear and precise, giving important
>> information to both the compiler and readers.
>
> But then you have to be sure that this logical fact is true;
> since it is an iron-clad assertion, the justification behind it
> (which the compiler doesn't see nor care about) has to be iron
> clad.

Yes.

But if I write "p++;", I also have to be absolutely sure that this is
the correct action at the time. That's how programming works - I really
do not see why anyone would think "unreachable();" is so special.

>
> There is a risk in it because it's possible that if you neither
> add "return 0" nor "unreachable()" that the situation might not
> be erroneous at all if that end is reached.
>

"Possibly not erroneous" implies "possibly erroneous", which - by
definition - means "undefined behaviour", because you can't be sure
about what will happen. So you are worried about adding explicit
undefined behaviour in a situation where you currently already have
undefined behaviour?

Do you understand why I don't see writing "unreachable();" as
particularly dangerous, compared to anything else in the code?

> Whereas with unreachable() that becomes UB.
>>
>>> If the programmer is wrong however, 'unreachable()' won't stop garbage
>>> (which can include a misleadingly correct result) from being returned.
>>
>> That is true. But if the programmer is wrong and writes "return 0;" in
>> the wrong place, things could go equally badly.
>
> Not there though; somewhere farther down the road where the can has
> been kicked. But yes.

If the problem manifests itself later, it can be harder to find. With
"unreachable();", compilers can support debugging options to help if
you've made an error and the line is /not/ unreachable. And if they
don't have convenient debugging options, it's also easy to use a macro
here, then redefine the macro to print an error and call abort() when
fault-finding. Tracing a mistaken "return 0;" is a lot harder.

>
>> When programmers write
>> the wrong thing, bad things may happen - that's inevitable in
>> programming. One way to minimise the risk of that is by writing code
>> that makes sense - say what the code does, such as writing
>> "unreachable();" when you know that line cannot be reached, rather than
>> writing nonsense such as "return 0;" when the code cannot return from there.
>
> Or abort() when that makes sense; like that it would be bad for that
> code to be reached, and we don't think it is, but we are not so
> committed to that proposition that we're willing to bet on it with
> undefined behavior. And we don't mind the extra instructions for that in
> that situation.
>

Write "abort();" if that's what you want. But it is not an extra
instruction - it is much more invasive than that in many cases. It can
turn what would be a simple inlined function, or a "pure" function (one
that has no side effects, and whose return value is solely and
consistently dependent on the parameters) into a semantically far more
complicated function that can have major effects.

On 09/09/2023 03:48, Kaz Kylheku wrote:
> On 2023-09-08, Bart <bc@freeuk.com> wrote:
>> It's funny that some people don't want the bother of writing 'return 0;'
>> in a path they know will never be reached, while others are prepared to
>> write 'unreachable();', which is both longer and uses shifted characters.
>
> What is worse, the original program with a missing "return 0;" might
> well be correct. If the caller doesn't extract the return value,
> everything is copacetic.
>
> Whereas unreachable() is a gizmo whose only meaning is that it invokes
> undefined behavior if executed!
>
> It's like you have a pepper shaker on your programing table labeled
> "UB", and you sprinkle that on your program.
>

That's the joy of undefined behaviour :-)

Several years back, I had to deal with finding bugs in a code base where
the programmer had regularly muddled up function parameters and return
types. Most people like to have global functions declared in a header,
and include that header in the C file that defines the function and any
C files that use the function - then they get everything nice and
consistent. The code base that this programmer had started with, before
he screwed around with it, was organised like that. (I know - I wrote
it, and my gcc setup will complain loudly if there are any missing or
mismatched declarations.) But this guy frequently didn't bother
including headers, or declaring his global functions in headers.
Sometimes he had an extern declaration in the C file, sometimes he
relied on ancient implicit function declaration. And he got it wrong -
a lot. Functions would be defined with one set of parameters, and
called from different C files with a different number or different type
of parameters. Return types were equally random.

But you can't just replace a missing "return x;" with "return 0;", even
though the behaviour is defined. Sometimes the code without the return
statement works by sheer luck, which the "return 0;" is a guaranteed and
consistent failure.

It had one feature I've never seen before, tying in with another thread
here - it called main() recursively. From within an interrupt handler.