[cfe-dev] missing return statement for non-void functions in C++

Marshall Clow mclow.lists at gmail.com
Tue Jul 28 15:40:55 PDT 2015


On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer <sjoerd.meijer at arm.com>
wrote:

> Hi,
>
>
>
> In C++, the undefined behaviour of a missing return statements for a
> non-void function results in not generating the function epilogue
> (unreachable statement is inserted and the return statement is optimised
> away).  Consequently, the runtime behaviour is that control is never
> properly returned from this function and thus it starts executing “garbage
> instructions”. As this is undefined behaviour, this is perfectly fine and
> according to the spec, and a compile warning for this missing return
> statement is issued. However, in C, the behaviour is that a function
> epilogue is generated, i.e. basically by returning uninitialised local
> variable. Codes that rely on this are not beautiful pieces of code, i.e are
> buggy, but it might just be okay if you for example have a function that
> just initialises stuff (and the return value is not checked, directly or
> indirectly); some one might argue that not returning from that function
> might be a bit harsh.
>

I would not be one of those people.


> So this email is to probe if there would be strong resistance to follow
> the C behaviour? I am not yet sure how, but would perhaps a compromise be
> possible/acceptable to make the undefined behaviour explicit and also
> generate the function epilogue?
>

"undefined behavior" is exactly that.

You have no idea what is going to happen; there are no restrictions on what
the code being executed can do.

"it just might be ok" means on a particular version of
a particular compiler, on a particular architecture and OS, at
a particular optimization level.  Change any of those things, and you can
change the behavior.

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150728/92f9995e/attachment.html>


More information about the cfe-dev mailing list