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

Aaron Ballman aaron at aaronballman.com
Thu Jul 16 07:12:09 PDT 2015


On Thu, Jul 16, 2015 at 9:54 AM, Andrew Parker
<andrew.j.c.parker at gmail.com> wrote:
> 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.

Which it is allowed to do.

>  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 believe libc++ relies on the ABI libraries to provide these default
implementations, but I'm not 100% certain as I'm not a libc++ expert.

> 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?

Others may have a better answer than me, but I am not certain it's
worth the added complexity for deprecated functionality.

~Aaron

>
> 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
>> >
>
>




More information about the cfe-dev mailing list