Re: Mark va_start as nothrow

[Richard Guenther <richard dot guenther at gmail dot com>]

2009/4/17 Mark Mitchell <mark@codesourcery.com>:
> Jan Hubicka wrote:
>
>> Thinking about this more, the non-call-exceptions and use of any of C++
>> standard library is iffy. ?It is not built with the flag and thus any
>> kind of ICE will not be properly handled anyway.
>
> It's not built that way by default. ?Is it impossible to build it that way?
>
>> One can not resonably
>> expect sprintf to produce sane non-call-exception
>
> If you don't control the run-time library, yes, that's true.
>
>> Since -fnon-call-exceptions is really Java thingy, where C++ runtime is
>> irrelevant, I am not sure how much better we need to be on builtins.
>> If it seems, we can hope for some sanity here, I will add the NCE_LISTs.
>
> People do use it with C and C++, but I don't know how much. ?I think
> va_arg is different from sprintf; va_arg is implemented entirely in bits
> we control.
>
> I wasn't sure from Richard's email if he was suggesting just ignoring
> throw specifications in the presence of -fnon-call-exceptions. ?I don't
> know exactly what to say about that. ?My first reaction is that the
> exception generated by a memory fault when compiling with
> -fnon-call-exceptions should result in a call to std::unexpected if
> uncaught with in a region that has a throw-specification that does not
> permit the exception.

That would work for the C++ runtime (built with -fexceptions), but for
example glibc annotates functions with throw() as well, without
catching uncaught exceptions (I'm not even sure there is an equivalent
for C, even if we would build with -fexceptions?).

Richard.