Hacker News Reader

Comment by fluoridation | Hacker News Reader

If a code path that's supposed to be unreachable is reached then the program is already broken. Unless it has a bug, a compiler will not make a program more broken. At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

View on HN

Yes, but what was unreachable may get reachable as I do changes to the program. I see the utility when doing highly optimized library code.

But for my purposes I much prefer to stick something which flags me (exception or logging or whatever) of "this should never happen" instead of crashing. (Undefined.)

In a real codebase, this would be wrapped by a macro to abort in a debug build but gain the optimizations in a release build.

cppreference suggests this as an implementation for std::unreachable but as near as I can tell neither clang nor MSVC does that (yet?).

I would have expected the _LIBCXX_ASSERTIONS macro in libc++ to affect the behavior, similarly to many other standard library undefined behaviors.

Can't help but feel offended that my codebase isn't real. Thanks for the laugh though :-D

I'd rather have solid logging and/or abort handling than some extra yak hairs shaved off the speed on my release builds. I'm weird that way.

> At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

An abort would make them obvious, surely unreachable makes them less obvious?

The point is that you're telling the compiler "I don't care what happens if control reaches here. Assume it never will and use that information to better optimize the rest". It's not an alternative to abort() or throwing because the compiler still needs to generate code for them.

Yes, that’s what I mean, the compiler can completely remove a branch which is unreachable, along with any checks. If it was forced to keep the checks and report an error instead, any bug would be more obvious. If the compiler removes checks for bugs, then the application could silently continue, obscuring the bug.

So this is a “hide bugs but maybe improve performance” function.

No, it doesn't hide bugs. It has no defined effect on the obviousness of bugs. The reason is that modern compilers are pretty much theorem solvers, and they're able to propagate truth values in order to deduce facts about programs. For example, a compiler could deduce that since a branch is never reached, a particular pointer is never null, and could therefore skip a null check that it deduced was redundant that would have prevented a null dereference. If it turns out that the branch is reachable and the pointer is null, the pointer would be dereferenced and the program would crash immediately (typically). But UB is UB; once you hit it all behaviors are permissible, from immediate crash, to silent data corruption, to nasal demons.

It's undefined behavior. The compiler is free to do whatever, including making your program more broken.

If you have undefined behavior, your program is already broken. No such thing as "more broken"; there's already no theoretical limit to what might happen if it gets triggered.

Undefined behavior is considered worse than crashing, which is typically the alternative when reaching "unreachable" codepaths.

Compare these two blocks similar to the article

   switch (ch) {
   case 'a': do_a(); return;
   case 'd': do_d(); return;
   // ch is guaranteed to be 'a' or 'd' by previous code.
   default: assert(0);
   }

   switch (ch) {
   case 'a': do_a(); return;
   case 'd': do_d(); return;
   default: std::unreachable();
   }

If the programmer is wrong about `ch` in the first one, the program terminates. For the second one, the compiler could change it to be equivalent to

  if (ch == 'a') { do_a(); }
  else { do_d(); }
  return;

If the programmer is wrong here, the program might `do_d()` with unintended consequences. I'd say "going down unintended codepaths" is typically considered worse than crashing.

N.b. fixed last code example- thanks afiori.

I suspect you meant to omit the `if (c == 'd')` part in the last example

I take your point, but you can get the behavior of your first example, while still marking the default branch with std::unreachable(), by asserting the preconditions before the switch. This seems to me to be a pretty general equivalence.

So what does std::unreachable() do here? In this particular case, and with NDEBUG defined and any level of optimization selected, I suspect that, at a minimum, the switch would be replaced as you have shown in all versions - it would take a more complex example to show how std::unreachable() makes a difference. The point is, now we have a choice - and it is one that is being offered without creating any backwards-compatibility issues.

Furthermore, the original function, without assertions, is not guaranteed to crash, with or without std::unreachable(). You need some explicit checks to get a desirable response in the case where a mistake has been made, and that option is just as available whether or not you use std::unreachable().

Therefore, while I agree you have shown that not all broken variants of a given program are equivalent, this does not show that std::unreachable() is harmful.

I get your point, but assert is usually removed in release builds. Abort would probably be better if you want to crash the program.

I find it unhelpful to frame undefined behavior as an “escape hatch” that lets the compiler do anything it wants. Compiler writers aren’t gleefully hunting for issues and using its presence as an excuse to make your life miserable. Instead, the weirdness arises because the compiler makes certain assumptions and transforms the code in ways that depend on them. For example:

1. Null pointers are never dereferenced.

2. Ptr *p is dereferenced.

3. p therefore cannot be null.

4. Ergo, we can omit checking whether p is null.

If the initial premise isn’t actually true (i.e., you slip up and dereference a null pointer), the chain of logic breaks down and boom! Applying many such rules can certainly lead to weird emergent behavior—and maybe you should act as if anything can happen—but it’s not a total free-for-all.

Reply on news.ycombinator.com