This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> 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
way.

    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, 

  #if NO_EXCEPTIONS
  #define try if (true)
  #define catch(x) if (false)
  #endif

This works because try and catch blocks are always enclosed in
braces.

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
is made.

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

Right.

    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                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]