<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 10:12 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jul 16, 2015 at 9:54 AM, Andrew Parker<br>
<<a href="mailto:andrew.j.c.parker@gmail.com">andrew.j.c.parker@gmail.com</a>> wrote:<br>
> I personally think the standard is poorly defined here.  It allows for the<br>
> case that get_unexpected can return null.  It also allows it to be legal to<br>
> call set_unexpected with null, but doesn't specify whether that means set<br>
> the default handler.<br>
><br>
> libc++ allows null but unexpected() will crash if called in when the<br>
> unexpected handler is null.<br>
<br>
</span>Which it is allowed to do.<br>
<span class=""><br>
>  Also it doesn't have any code to set the<br>
> default handler out of the box (unless I'm missing something).  Any idea why<br>
> this is the case?  The reason I brought this up is that tests were asserting<br>
> and crashing for me (with MSVC) because in my build I haven't (yet) done<br>
> anything to set a default.<br>
<br>
</span>I believe libc++ relies on the ABI libraries to provide these default<br>
implementations, but I'm not 100% certain as I'm not a libc++ expert.<br>
<span class=""><br></span></blockquote><div>Yes, I think you're right and this probably addresses the crux of my issues. I've been using libc++abi on GNU platforms but that's not viable with MSVC.  Spent too long with my head in VC and missed this piece of the puzzle.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I personally think the robust solution for behaviour is to return null from<br>
> the outset and have std::unexpected just call terminate if the current<br>
> handler is null.  That way there's no nasty behaviour.  However, if the<br>
> choice for libc++ is to have a non-null handler then is there any reason not<br>
> to add code to set that automatically (to std::terminate) and possibly add<br>
> code to do something sane when null is passed in?<br>
<br>
</span>Others may have a better answer than me, but I am not certain it's<br>
worth the added complexity for deprecated functionality.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>I think given the dependency on libc++abi I tend to agree.  Whilst I dislike coupling/dependencies, it's pretty minor and given it's deprecated even more so.  Thanks for the input! </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Anyway, I won't stress too much about this as it's deprecated in c++11 and<br>
> not going to end my world.  Just curious as to why things are the way they<br>
> are.<br>
><br>
> On Thu, Jul 16, 2015 at 7:55 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Wed, Jul 15, 2015 at 11:56 PM, Andrew Parker<br>
>> <<a href="mailto:andrew.j.c.parker@gmail.com">andrew.j.c.parker@gmail.com</a>> wrote:<br>
>> > The test:<br>
>> ><br>
>> ><br>
>> > \test\std\depr\exception.unexpected\set.unexpected\get_unexpected.pass.cpp<br>
>> ><br>
>> > expects the initial unexpected handler to be non-NULL:<br>
>> ><br>
>> > int main()<br>
>> > {<br>
>> ><br>
>> >     std::unexpected_handler old = std::get_unexpected();<br>
>> >     // verify there is a previous unexpected handler<br>
>> >     assert(old);<br>
>> ><br>
>> > Is that really a requirement?<br>
>><br>
>> I believe so, yes. [unexpected.handler]p3 says: "The implementation’s<br>
>> default unexpected_handler calls std::terminate()." which suggests<br>
>> that there be an initial default unexpected_handler that is nonnull.<br>
>><br>
>> ~Aaron<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" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>