Hacker News Reader

Comment by Aurornis | Hacker News Reader

I never would have guessed that the unreachable() function would get executed in that example. Probably not something you’d encounter in practice, though I have seen some weird things happen with layers of #ifdef

View on HN

> Probably not something you’d encounter in practice

it's actually probably the most common footgun you'll encounter in practice: non-void functions with no return statements just keep executing past their end. ask me how i know.

compile with -Wreturn-type if you want to avoid such things...

> compile with -Wreturn-type if you want to avoid such things...

Isn't -Wreturn-type enabled by default in both gcc and clang atleast for c++?

probably - i guess then i meant -Werror=return-type

C on the other hand puts an implicit `return 0` at the end, but only on the main function for some reason. Very weird.

C++ also special-cases the `main` function. Probably because `main` is the interface to the OS so it gets special language treatment.

In C++ you're not allowed to call main yourself, so that the compiler can call the global constructors at the start of main.

Which also exist as C extensions, in some compilers.

In C. In C++ it's an error to not return, as it should be.

.... The blog post literally demonstrates that it is not. Feel free to repro on your own machine.

The main function in the blog post returns at the end of all control paths. Firstly because main has an implicit "return 0" at the end and secondly because no control paths end. It doesn't jump to unreachable because it lacks a return - it jumps there because that's how this implementation has chosen to compile UB, despite the presence of all necessary returns.

That's kind of what you get with UB; the compiler doesn't need to do what you expect.

Reply on news.ycombinator.com