[cfe-dev] Reaching the end of a value-returning function in C++

[Richard Smith]

On Fri, Oct 12, 2012 at 7:07 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>wrote:

> On Oct 4, 2012, at 4:56 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> > As of r165273, clang produces 'unreachable' if we flow off the end of a
> value-returning function (without returning a value) in C++. This is
> undefined behavior, but we used to just return undef, instead of trying to
> exploit it. Please let me know if this causes problems for you, and we can
> weaken it to an acceptable level.
>
> FYI, this caused some libc++ tests to crash (or not terminate). To
> highlight one example, there was this method:
>
> > template <class _CharT, class _Traits>
> > inline _LIBCPP_INLINE_VISIBILITY
> > basic_filebuf<_CharT, _Traits>&
> > basic_filebuf<_CharT, _Traits>::operator=(basic_filebuf&& __rhs)
> > {
> >     close();
> >     swap(__rhs);
> > }
>
> Notice the absence of a "return *this".
>
> At the test
> (test/input.output/file.streams/fstreams/filebuf.assign/move_assign.pass.cpp)
> the method was used like this:
>
>  std::filebuf f2;
>  f2 = move(f);
>
> Notice that the returned value from 'operator=' is ignored.
>
> There was a crash with a stack trace showing bad access inside
> "libunwind.dylib`_Unwind_Resume"; the stack trace didn't provide much hint
> at what the culprit is.
>
> I don't think producing 'unreachable' always by default is a good idea;
> this is too aggressive to do at the frontend level and it makes debugging
> (on a "-O0 -g" build) a nightmare.


Yeah, we were worried that this might be a problem for people who don't use
-Wreturn-type. How would you feel about inserting a call to llvm.trap
before the unreachable if we're building without optimizations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121014/9d0d4cd6/attachment.html>