[cfe-dev] (libc++) get_unexpected expected to return non-NULL

Andrew Parker andrew.j.c.parker at gmail.com
Thu Jul 16 06:54:46 PDT 2015


I personally think the standard is poorly defined here.  It allows for the
case that get_unexpected can return null.  It also allows it to be legal to
call set_unexpected with null, but doesn't specify whether that means set
the default handler.

libc++ allows null but unexpected() will crash if called in when the
unexpected handler is null.  Also it doesn't have any code to set the
default handler out of the box (unless I'm missing something).  Any idea
why this is the case?  The reason I brought this up is that tests were
asserting and crashing for me (with MSVC) because in my build I haven't
(yet) done anything to set a default.

I personally think the robust solution for behaviour is to return null from
the outset and have std::unexpected just call terminate if the current
handler is null.  That way there's no nasty behaviour.  However, if the
choice for libc++ is to have a non-null handler then is there any reason
not to add code to set that automatically (to std::terminate) and possibly
add code to do something sane when null is passed in?

Anyway, I won't stress too much about this as it's deprecated in c++11 and
not going to end my world.  Just curious as to why things are the way they
are.

On Thu, Jul 16, 2015 at 7:55 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Wed, Jul 15, 2015 at 11:56 PM, Andrew Parker
> <andrew.j.c.parker at gmail.com> wrote:
> > The test:
> >
> >
> \test\std\depr\exception.unexpected\set.unexpected\get_unexpected.pass.cpp
> >
> > expects the initial unexpected handler to be non-NULL:
> >
> > int main()
> > {
> >
> >     std::unexpected_handler old = std::get_unexpected();
> >     // verify there is a previous unexpected handler
> >     assert(old);
> >
> > Is that really a requirement?
>
> I believe so, yes. [unexpected.handler]p3 says: "The implementation’s
> default unexpected_handler calls std::terminate()." which suggests
> that there be an initial default unexpected_handler that is nonnull.
>
> ~Aaron
>
> >
> > _______________________________________________
> > 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/20150716/a1620608/attachment.html>


More information about the cfe-dev mailing list