[PATCH] RE: missing return statement for non-void functions in C++

Hi, I am not sure if we came to a conclusion. Please find attached a patch. It simply removes the two lines that insert an unreachable statement (which cause removal of the return statement). Please note that at -O0 the trap instruction is still generated. Is this something we could live with?

Cheers,

Sjoerd.

missingreturn.diff (509 Bytes)

Hi, I am not sure if we came to a conclusion. Please find attached a
patch. It simply removes the two lines that insert an unreachable statement
(which cause removal of the return statement). Please note that at -O0 the
trap instruction is still generated. Is this something we could live with?

I don't think this is an improvement:

This doesn't satisfy the folks who want an 'unreachable' for better code
size and optimization, and it doesn't satisfy the folks who want a
guaranteed trap for security, and it doesn't satisfy the folks who want
their broken code to limp along (because it'll still trap at -O0), and it
is at best a minor improvement for the folks who want missing returns to be
more easily debuggable (with -On, the code goes wrong in the caller, or
appears to work, rather than falling into an unrelated function, and
debugging this with -O0 was already easy).

I think there are three options that are defensible here:
1) The status quo: this is UB and we treat it as such and optimize on that
basis, but provide a trap as a convenience at -O0
2) The secure approach: this is UB but we always trap
3) Define the behavior to return 'undef' for C types: this allows
questionable C code that has UB in C++ to keep working when built with a
C++ compiler

Note that (3) can be combined with either (1) or (2). (2) is already
available via the 'return' sanitizer. So this really reduces to: in those
cases where C says it's OK so long as the caller doesn't look at the
returned value (and where the return type doesn't have a non-trivial copy
constructor or destructor, isn't a reference, and so on), should we attempt
to preserve the C behaviour? I would be OK with putting that behind a `-f`
flag (perhaps `-fstrict-return` or similar) to support those folks who want
to build C code in C++, but I would suggest having that flag be off by
default, since that is not the usual use case for a C++ compiler.

Cheers,

Hi Richard,

I agree with your conclusions and will start preparing a patch for option 3) under a flag that is off by default; this enables folks to build/run C code in C++. I actually think option 2) would be a good one too, but as it is already available under a flag I also don’t see how useful it is combining options 2) and 3) with another (or one more) flag that is off by default.

Cheers.