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

[Benjamin Kosnik <bkoz at redhat dot com>]

Mark, I would rather not do this to the library code. However, it is 
something that v2 can do that v3 cannot: thus, I take it pretty seriously.

I think v3 should be able to do this. It would be nice if adding this 
support could be done in a way that preserved the integrity and flow of 
the v3 code in question. I think I proposed something that is sane.

Reasonable people may disagree. Frankly, I'm surprised Jason agreed.

I think the current -fno-exceptions behavior is not as well 
defined as you might believe. Why would try statements be ignored, but 
not catch? Hmm? I guess the comments in gcc.info.......

...Oh wait. there are no comments describing this flag. Whoops. What is it 
supposed to do, anyway? In what ways is -fno-exceptions in g++ like other 
compilers? Different? The EDG 2.44 docs I looked at don't really explain, 
just say options for turning on and off exceptions exist. 

I'm not trying to be difficult, but is there any way I can get you to 
explain what you think -fno-exceptions should do? Can we start with what 
the current behavior WRT try/catch blocks are with -fno-exceptions?

And:

Code that depends on real exceptions being throw will fail regardless of 
the proposed  -fno-exceptions behavior. 

If this is renamed a different option, may I suggest using -fdeprecated-xxx 
or something, implying that this is something that will eventually be removed.
(I'm thinking about doing the same for the headers currently named 'backward')


(Can't we trade removing pragma interface/implmentation for sane -fno-exception semantics?)

;)

-benjamin

> I'm strongly against having the compiler silently ignore/transform
> try/catch when we see -fno-exceptions.
> 
> That is different behavior from what most other vendors have chosen,
> it increases complexity in the front-end, and it's potentially very
> confusing to users, since code that *depends* on real exceptions
> occurring will silently break.  (Issuing a warning really isn't good
> enough; too many people don't look at them.)
> 
> If we do this at all, we should have a -ftransform-exceptions switch
> that is *different* from -fno-exceptions; there are already
> expectations in place about what -fno-exceptions means.