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

[James Molloy]

Hi,

If we're going to emit a trap instruction (and thus create a broken
binary), why don't we error instead?

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/5559bd9a/attachment.html>