This is the mail archive of the
mailing list for the libstdc++ project.
Re: patch: <bits/localefwd.h> with -fno-exceptions
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: patch: <bits/localefwd.h> with -fno-exceptions
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Thu, 18 Jan 2001 19:37:33 -0800 (PST)
- cc: jason at redhat dot com, libstdc++ at gcc dot gnu dot org
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?
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?)
> 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.