patch: <bits/localefwd.h> with -fno-exceptions

[Jason Merrill]

>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:

> Jason, this is an example of code that is causing problems in current CVS:

> int main()
> {
>   int i;
>   try { 
>     i++;
>   } 
>   catch(...) { 
>   }
>   return 0;
> }

> It's dying on the catch statement.

Well, yes.  Nathan was talking about throw specs.

> The best approach, as far as I'm concerned, would be to transform try
> and catch blocks as follows when using -fno-exceptions, so that the
> library people (and the rest of g++ users, incidentally) only had to
> worry about throw statements.

Hmm.  If we compile with -fno-exceptions, we are asserting that no
exceptions will propagate through the code being compiled--indeed, with
dwarf2 EH, any that try will go to terminate()--so ignoring the catch
blocks could be considered a straightforward optimization.

OK, then.  But I can't promise to do this work soon.

> Then the library would only need to clean up stuff like 

> throw std::out_of_range("here");

> we could just use inline-functions and configure hackery / soft links
> to switch between a

> void
> __throw_out_of_range(const char* __s)
> { throw std::out_of_range(__s); }

> and

> unsigned long __glibcpp_exception;

> void
> __throw_out_of_range(const char* /*__s*/)
> { __glibcpp_exception = 5; }

> or whatever.

Um, how would you propose to handle error-recovery using
__glibcpp_exception?  Looking at the SGI code, when they encounter a
problem where they would have thrown an exception, instead they just call
abort and fall over.  This seems reasonable to me; if people want to
recover cleanly from problems, well, that's what EH is for.

Jason