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

[David Blaikie]

On Jul 29, 2015 2:10 AM, "mats petersson" <mats at planetcatfish.com> wrote:
>
>
>
> On 28 July 2015 at 23:40, Marshall Clow <mclow.lists at gmail.com> wrote:
>>
>>
>>
>> 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.
>
>
> Nor me.
>>
>>
>>>
>>> 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.
>
>
> In fact, the "it works kind of as you expected" is the worst kind of UB
in my mind. UB that causes a crash, stops or other "directly obvious that
this is wrong" are MUCH easier to debug.
>
> So make this particular kind of UB explicit by crashing or stopping would
be a good thing. Making it explicit by "returning kind of nicely, but not
correct return value" is about the worst possible result.

At -O0 clang emits a trap instruction, making it more explicit as you
suggest. At higher optimization levels it just falls through/off.

>
> --
> Mats
>>
>>
>> -- Marshall
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150729/29f678b4/attachment.html>