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

[mats petersson]

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.

--
Mats

>
> -- Marshall
>
>
> _______________________________________________
> 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/f6ab9a1e/attachment.html>