<p dir="ltr"><br>
On Jul 29, 2015 7:06 AM, "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> If we're going to emit a trap instruction (and thus create a broken binary), why don't we error instead? </p>
<p dir="ltr">We warn, can't error, because it may be dynamically unreached, in which case the program is valid and we can't reject it.</p>
<p dir="ltr">><br>
> James<br>
><br>
> On Wed, 29 Jul 2015 at 15:05 David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> On Jul 29, 2015 2:10 AM, "mats petersson" <<a href="mailto:mats@planetcatfish.com">mats@planetcatfish.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On 28 July 2015 at 23:40, Marshall Clow <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer <<a href="mailto:sjoerd.meijer@arm.com">sjoerd.meijer@arm.com</a>> wrote:<br>
>> >>><br>
>> >>> Hi,<br>
>> >>><br>
>> >>>  <br>
>> >>><br>
>> >>> 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.<br>
>> >><br>
>> >><br>
>> >> I would not be one of those people.<br>
>> ><br>
>> ><br>
>> > Nor me. <br>
>> >><br>
>> >>  <br>
>> >>><br>
>> >>> 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?<br>
>> >><br>
>> >><br>
>> >> "undefined behavior" is exactly that.<br>
>> >><br>
>> >> You have no idea what is going to happen; there are no restrictions on what the code being executed can do.  <br>
>> >><br>
>> >> "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.<br>
>> ><br>
>> ><br>
>> > 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.<br>
>> ><br>
>> > 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.<br>
>><br>
>> At -O0 clang emits a trap instruction, making it more explicit as you suggest. At higher optimization levels it just falls through/off.<br>
>><br>
>> ><br>
>> > --<br>
>> > Mats<br>
>> >><br>
>> >><br>
>> >> -- Marshall<br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> cfe-dev mailing list<br>
>> >> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > cfe-dev mailing list<br>
>> > <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>