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

[James Molloy]

Hi,

I'm definitely in the other camp to Marshall and Mats on this one. I don't
believe that such aggressive optimization of undefined behavior should be
done unless there is a tangible benefit. I think we can all agree that some
UB, like the treatment of signed/unsigned wrap, can eventually end up with
optimizations on a correct program that wouldn't otherwise be possible.

But what optimization can this treatment of UB enable? I can't see how a
well formed program would benefit from this. And if no well formed program
can benefit, what is the use in deliberately destroying non-well-formed
programs? We all know that legacy code exists; I don't believe it's right
that we break them just because we can. Or because someone took a
conforming C program and ran it through a C++ compiler!

I'm fully prepared for backlash here though (or someone showing the actual
benefit of this treatment of UB on well-formed programs).

Cheers,

James

On Wed, 29 Jul 2015 at 10:23 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.
>
> --
> 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/df24a3f1/attachment.html>