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

[Aaron Ballman]

On Wed, Jul 29, 2015 at 5:53 AM, James Molloy <james at jamesmolloy.co.uk> wrote:
> 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 would go one step further and claim that this optimization may be
actively harmful as it can result in security vulnerabilities
depending on the arbitrary instructions executed. If there's a good
optimization story for this UB on well-formed programs, I would be
perfectly happy to support the current behavior as it *is* UB.
However, if there's not a compelling story for the behavior, I would
strongly prefer something with a smaller security vulnerability
footprint.

~Aaron

>
> 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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>