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

[David Blaikie]

On Jul 29, 2015 7:06 AM, "James Molloy" <james at jamesmolloy.co.uk> wrote:
>
> Hi,
>
> If we're going to emit a trap instruction (and thus create a broken
binary), why don't we error instead?

We warn, can't error, because it may be dynamically unreached, in which
case the program is valid and we can't reject it.

>
> James
>
> On Wed, 29 Jul 2015 at 15:05 David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>> 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
>> >
>>
>> _______________________________________________
>> 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/1d93b23e/attachment.html>