When the Debugger Lies - hckrnws

hckrnws

When the Debugger Lies

(danielmangum.com)

72

19

3d

by hasheddan

jcranmer
51d
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.
1. VorpalWay
  31d
  There may be differences between C and C++ here (and I worked with C++ more recently than C), but: if that enum doesn't specify an underlying type it would be UB to have a value that isn't in the "member list" of the enum. In that case it should be possible to determine if all cases are covered.
  If an underlying type is specified, then it should error since it is legal to have those values (unless the whole range of the underlying type is covered by the cases.
  Again, that is what would be sensible from a C++ perspective, I don't know if C differs here.
  EDIT: Also, and now I'm talking with my Rust user hat on: it is better to not have pointless UB. Yes some is needed to practically allow for optimisation. But C and C++ had a lot of UB that doesn't really help with making your code faster, such as this.
  1. throw324523
    01d
    > Again, that is what would be sensible from a C++ perspective, I don't know if C differs here.
    In C it is not UB for an enum to have an integer value that does not correspond to any listed enumeration constants.
  2. hn_go_brrrrr
    11d
    I don't think your C++ comment is true, otherwise you wouldn't be allowed to OR together C enums. I think the restriction is on values wider than the underlying type, where the underlying type is always wide enough to support any representable bit pattern.
2. gpderetta
  01d
  At the very least that would warrant an explicit std::abort() or std::unreachable() at the end (or the C equivalent).
LoganDark
01d
I think I was using C++14 at the time...
Brian_K_White
01d
It seems like something that could have been trapped right in k&r.
Was it ever even theoretically under any circumstances for any reason intended to be able to write a stack of functions with no returns that just fall into each other like assembly? I can't believe it.
So it seems like something even the very first compiler could have cought right in an early parser pass or stage.
But I also decline to believe I have a better idea about something than K or R, so there must be a non-triviality I don't see. I mean goto() exists in the language so ?
... I guess simply detecting the end of a function, or detecting that the process reached the end of a function, isn't a good enough definition of the problem. You can have any number of returns or gotos in the middle that you are always supposed to hit, and intentionally no return at the end because instead you have an assert or a goto.
assert you should never get here, goto error, goto not error but just next step, etc. They might or might not be error conditions that the process reached that spot, but it's not an error that the code doesn't end with a return.