[cfe-dev] [RFC][libcxx] Fix and maintain the no-exceptions build of libcxx

[Eric Lasota via cfe-dev]

There are cases where exceptions paths being UB is preferable for
optimization reasons, but I guess that's not common (MS's standard library
throws via an external call, libstdc++ calls abort()...).  Allowing a
custom handler sounds OK.

If you're going to change exceptional cases to call abort though, then it'd
be good to make other cases to be consistent with that approach, like
vector's __throw_length_error and __throw_out_of_range, regex's
__throw_regex_error, and possibly others.

On Fri, Nov 27, 2015 at 7:03 AM, Asiri Rathnayake <
asiri.rathnayake at gmail.com> wrote:

> Hello,
>
> Asserts getting optimized away is a problem, as then an exceptional code
> path will simply ignore the error and continue. Of course, one can argue
> that an exceptional state in a no-exceptions library is something that is
> OK to be ignored.
>
> In my latest patch [1], the user has the option to override the default
> abort behaviour by providing a custom __libcxx_noexceptions_abort()
> function. I think with this mechanism you can achieve the old behaviour if
> desired.
>
> Cheers,
>
> - Asiri
>
> [1] http://reviews.llvm.org/D14653
>
>
> On Thu, Nov 26, 2015 at 5:00 PM, via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
>> Wouldn’t the better thing to do be to assert rather than call abort (like
>> vector’s exceptions already do, for instance)?  One important use case of
>> no-exception builds is to completely optimize out throwing paths and the
>> checks leading to them, which wouldn’t happen if the exceptional path
>> called abort.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151128/e20d6cae/attachment.html>