This is the mail archive of the
mailing list for the libstdc++ project.
Re: patch: <bits/localefwd.h> with -fno-exceptions
>>>>> "Benjamin" == Benjamin Kosnik <firstname.lastname@example.org> writes:
Benjamin> Mark, I would rather not do this to the library
Benjamin> code. However, it is something that v2 can do that v3
Benjamin> cannot: thus, I take it pretty seriously.
It's much more important in embedded-land than in GNU System land.
There is a bit of schism about which of these matters more in GCC
development; the number-one item on the mission statement is
"supporting the goals of the GNU project, as defined by the FSF", so
we'd have to ask them which audience matters more.
On x86 non-embeded GNU/Linux, there's really not much need to do this.
On embedded MIPS with 64K ROM, it's vital.
Bottom line: I think it's definite major goodness, so let's find a
Benjamin> preserved the integrity and flow of the v3 code in
Benjamin> question. I think I proposed something that is sane.
There are other approaches. For example,
#define try if (true)
#define catch(x) if (false)
This works because try and catch blocks are always enclosed in
You may think it's ugly (and that's fair), but it actually does
exactly what you suggested, and requires no compiler magic. I think
that's a much easier, and better, approach.
Benjamin> Reasonable people may disagree. Frankly, I'm surprised
Benjamin> Jason agreed.
Me, too. England is making him soft. :-)
Benjamin> I think the current -fno-exceptions behavior is not as
Benjamin> well defined as you might believe. Why would try
Benjamin> statements be ignored, but not catch? Hmm? I guess the
Benjamin> comments in gcc.info.......
Benjamin> ...Oh wait. there are no comments describing this
Benjamin> flag. Whoops. What is it supposed to do, anyway? In what
Good point. Well, -fexceptions says "enable exception handling" so I
think -fno-exceptions would be "disable exception handling". Now, we
can argue over what that means.
Benjamin> ways is -fno-exceptions in g++ like other compilers?
Benjamin> Different? The EDG 2.44 docs I looked at don't really
Benjamin> explain, just say options for turning on and off
Benjamin> exceptions exist.
Well, I can tell you what EDG *does*; with --no_exceptions you get a
hard error on any try-block, throw-expression, or throw-spec.
Benjamin> I'm not trying to be difficult, but is there any way I
Benjamin> can get you to explain what you think -fno-exceptions
Benjamin> should do? Can we start with what the current behavior
You're not being difficult, and yes. :-) I think it should do exactly
what --no_exceptions does in EDG, namely disable all support for
exception handling, and issue a hard error when any attempt to use it
Benjamin> Code that depends on real exceptions being throw will
Benjamin> fail regardless of the proposed -fno-exceptions
Benjamin> If this is renamed a different option, may I suggest
Benjamin> using -fdeprecated-xxx or something, implying that this
Benjamin> is something that will eventually be removed. (I'm
Benjamin> thinking about doing the same for the headers currently
Benjamin> named 'backward')
I'm sorry; I don't quite understand. Do you mean the new proposed
-fpretend-I-didnt-use-extensions-and-carry-on switch, or the present
-fno-exceptions switch? I'm confused. :-)
Benjamin> (Can't we trade removing pragma interface/implmentation
Benjamin> for sane -fno-exception semantics?)
Throw in AIX support in V3, and I'll consider it strongly. :-)
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com