Once upon a time I had to figure out an issue where I forgot a `return` statement at the end of a non-`void` function, so the C++ compiler happily omitted both RETs for some reason and let the program go straight into illegal instructions. That was fun to debug (not fun, I practically had to single-step through the entire program) because every time this happened the debugger was incredibly confused about what the fuck was going on and nothing made any sense.
It makes no sense to me that C and C++ didn't require a diagnostic for this, rather you hit UB.
I know that at least modern GCC and Clang will warn and/or error for this (not sure which as I use -Werror), but still, this is pointless UB to have.
And no, in this case I don't buy that a C90 compiler would have been unable to check this.
Having been involved in the WG14 discussions on this topic:
The issue is that there is a contingent of users who complains about cases where the return dynamically can't be hit but that isn't obvious statically. Consider something like this:
int do_something(enum meow koala) {
switch (koala) {
case enum_val_1: return 5;
case enum_val_2: return 3;
/* etc., covering all the enum values */
}
}
Should this be required to diagnose? That's the sticking point.
LoganDark · · focus · HN ↗
VorpalWay · · focus · HN ↗
I know that at least modern GCC and Clang will warn and/or error for this (not sure which as I use -Werror), but still, this is pointless UB to have.
And no, in this case I don't buy that a C90 compiler would have been unable to check this.
jcranmer · · focus · HN ↗
The issue is that there is a contingent of users who complains about cases where the return dynamically can't be hit but that isn't obvious statically. Consider something like this:
Should this be required to diagnose? That's the sticking point.gpderetta · · focus · HN ↗