[Bug c++/25191] New: exception_defines.h #defines try/catch

[Bug c++/25191] New: exception_defines.h #defines try/catch

[hhinnant at apple dot com]

exception_defines.h #defines try/catch when -fno-exceptions.  This destroys
Objective C code using @try and @catch.  A simple fix is to insteaad in
exception_defines.h do something like (untested):

#ifndef __EXCEPTIONS
// Iff -fno-exceptions, transform error handling code to work without it.
# define __try      if (true)
# define __catch(X) if (false)
# define __throw_exception_again
#else
// Else proceed normally.
# define __try      try
# define __catch(X) catch(X)
# define __throw_exception_again throw
#endif

And then religiously use __try/__catch in libstdc++ instead of try/catch.


-- 
           Summary: exception_defines.h #defines try/catch
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hhinnant at apple dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-30 23:57 -------
This is a library issue and not a front-end issue.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[bkoz at gcc dot gnu dot org]

------- Comment #2 from bkoz at gcc dot gnu dot org  2005-12-02 18:59 -------

We are trying to keep the libstc++ code as clean and representative of
standards-conforming C++ code as possible, and have avoided __try, __catch,
etc. or other uglification in favor of the actual C++ terms, ie try, catch.

I'd rather you work around this in objective-c or objective c++.

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-02 19:01 -------
(In reply to comment #2)
> We are trying to keep the libstc++ code as clean and representative of
> standards-conforming C++ code as possible, and have avoided __try, __catch,
> etc. or other uglification in favor of the actual C++ terms, ie try, catch.
> 
> I'd rather you work around this in objective-c or objective c++.

Actaully I can think of why this cannot be worked around, first try is the
keyword and not just @try.

I personally would like this fixed in libstdc++ as it is changing valid code in
people's sources without them knowing it is happening to them (maybe an #undef
before the end of the header files will fix the issue).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-02 19:04 -------
Confirmed.  This also causes problems in normal C++ code which does:

#include <string>

int f(void);
int main(void)
{
  try {
  f();
  }catch (a) {}
}

Without the include, you get an error but with the include, you don't which is
inconstaint behavior.

So this is not just an obc++ vs libstdc++ with -fno-exceptions issue, this is
also an diagnostic issue.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-02 19:04:30
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07 -------
(In reply to comment #2)
> I'd rather you work around this in objective-c or objective c++.

How?  I'm open to suggestions.

-Howard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #6 from gdr at integrable-solutions dot net  2005-12-02 19:18 -------
Subject: Re:  exception_defines.h #defines try/catch


I agree with Benjamin.

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I personally would like this fixed in libstdc++ as it is changing
| valid code 

I don't think that can be true.

try and catch are C++ keyword.  And exceptions are integral part of
the language.  As a courtesy, libstdc++ lets you use it with
-fno-exceptions at the conditions that iy you use try and catch then
they are rewritten into the if(0)/else stuff.

| in 
| people's sources without them knowing it is happening to them (maybe an
#undef
| before the end of the header files will fix the issue).

#undef at the files of the files will not fix the issue.  However,
it is a good suggestion of how objc can fix the issue on its side.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #7 from gdr at integrable-solutions dot net  2005-12-02 19:23 -------
Subject: Re:  exception_defines.h #defines try/catch

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Confirmed.  This also causes problems in normal C++ code which does:
| 
| #include <string>
| 
| int f(void);
| int main(void)
| {
|   try {
|   f();
|   }catch (a) {}
| }
| 
| Without the include, you get an error but with the include, you don't which
is
| inconstaint behavior.

Indeed.  But that is not changing a valid code into something else as
you claimed earlier.

The use of try/catch is part of the contract of -fno-exceptions. If a
determined programmer decides to abuse them beyond reasons, then I
believe he/she gets what he/she gets.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #8 from gdr at integrable-solutions dot net  2005-12-02 19:29 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07 -------
| (In reply to comment #2)
| > I'd rather you work around this in objective-c or objective c++.
| 
| How?  I'm open to suggestions.

#undef them if you intend to include libstdc++ files and use try/catch
with funny characters to mean something else with -fno-exceptions?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #9 from hhinnant at apple dot com  2005-12-02 21:00 -------
(In reply to comment #8)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | ------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07 -------
> | (In reply to comment #2)
> | > I'd rather you work around this in objective-c or objective c++.
> | 
> | How?  I'm open to suggestions.
> 
> #undef them if you intend to include libstdc++ files and use try/catch
> with funny characters to mean something else with -fno-exceptions?

I'm sorry, I'm just not understanding what you're suggesting.  If you could
expound on your suggestion I would be most appreciative.  If it helps, here is
a demo file that I would like to have work with -fno-exceptions.

#include <list>
#include <vector>
#import <Cocoa/Cocoa.h>
#import "my_header.h"  // may have contain ObjC @try/@catch
#include <iostream>

int main()
{
//    ....
}

An alternative to my original suggested fix is to solve this problem in the FE
by parsing try/catch differently (e.g. as if they were if(true)/if(false)) in
system headers when -fno-exceptions.  Then we could just get rid of
exception_defines.h, and still have pretty std::headers.  Not being someone
with a lot of FE experience, I have more hesitation about this latter approach.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2005-12-02 21:06 -------
(In reply to comment #9)
> Not being someone with a lot of FE experience, I have more hesitation about this latter approach.

That solution still does not solve my issue of the diagnostic issue.  

We really should not be defining keywords in the headers at all.  If we define
bool somewhere to be int, we would get incorrect behavior the same way we are
getting for try/catch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #11 from hhinnant at apple dot com  2005-12-02 21:21 -------
(In reply to comment #10)
> (In reply to comment #9)
> > Not being someone with a lot of FE experience, I have more hesitation about this latter approach.
> 
> That solution still does not solve my issue of the diagnostic issue.  

Doesn't it?  try/catch is no longer #defined, and client code will get a
diagnostic if it uses try/catch with -fno-exceptions (only the system headers
get special treatment by the FE).  That's what we want, right?

> 
> We really should not be defining keywords in the headers at all.  If we define
> bool somewhere to be int, we would get incorrect behavior the same way we are
> getting for try/catch.
> 

<nod>  That's always been a golden rule that has worked well for me (after
learning it the hard way many moons ago ;-) ).

-Howard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #12 from gdr at integrable-solutions dot net  2005-12-03 00:58 -------
Subject: Re:  exception_defines.h #defines try/catch

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| We really should not be defining keywords in the headers at all.  If we
define
| bool somewhere to be int, we would get incorrect behavior the same way we are
| getting for try/catch.

But the issues are not the same.  You're using try/catch with
-fno-exceptions!  If you used a compiler options that tells you that
bool is defined to something else, that is it!  

-- gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #13 from gdr at integrable-solutions dot net  2005-12-03 01:02 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #8)
| > Subject: Re:  exception_defines.h #defines try/catch
| > 
| > "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| > 
| > | ------- Comment #5 from hhinnant at apple dot com  2005-12-02 19:07
-------
| > | (In reply to comment #2)
| > | > I'd rather you work around this in objective-c or objective c++.
| > | 
| > | How?  I'm open to suggestions.
| > 
| > #undef them if you intend to include libstdc++ files and use try/catch
| > with funny characters to mean something else with -fno-exceptions?
| 
| I'm sorry, I'm just not understanding what you're suggesting.  If you could
| expound on your suggestion I would be most appreciative.  If it helps, here
is
| a demo file that I would like to have work with -fno-exceptions.

I'm saying that if you're intending to use try/catch and yet not
want what the mean in standard C++, nor what they would mean in GNU
C++ with -fno-exceptions, then you have to watch what you're doing.
Meaning, in your *own* codes, you #undef try/catch.  Whether it is in
Cocoa.h or foobar.c, I don't care.  Just take your responsability to
#undef them -- because you have decided to have mean something else.
I'm not inclined in seeing the libstdc++ be uglified in that direction.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #14 from hhinnant at apple dot com  2005-12-03 01:25 -------
(In reply to comment #13)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> I'm saying that if you're intending to use try/catch and yet not
> want what the mean in standard C++, nor what they would mean in GNU
> C++ with -fno-exceptions, then you have to watch what you're doing.
> Meaning, in your *own* codes, you #undef try/catch.  Whether it is in
> Cocoa.h or foobar.c, I don't care.  Just take your responsability to
> #undef them -- because you have decided to have mean something else.
> I'm not inclined in seeing the libstdc++ be uglified in that direction.

I see, thanks for the clarification.

It is my understanding that gcc 4.1 supports a language called Obj C++.  In
this language (and I am by no means an Obj C++ expert) you can pretty much mix
& match Obj C and C++.  I have customers using Obj C++ who want to turn off C++
exception support, but retain Obj C exception support.  They can easily do so
-- unless they include a libstdc++ header.  The libstdc++ headers are messing
up their ObjC @try/@catch statements.  That is, libstdc++ is not supportive of
ObjC++ in this manner.

They are not trying to use C++ try/catch in a bizarre or unsupported manner. 
They are simply trying to use ObjC++ exceptions without the unwanted cost of
C++ exceptions.

This is quite analogous to the C headers compiled under C++.  <math.h>, under
C++, is supposed to behave a little differently than <math.h> under C.  As a
C++ programmer I appreciate that some C vendors will make some modest
accomadations for me.

This seems to me like a very modest accomadation we can make for the ObjC++
programmer.  Afterall, ObjC++ is a supported language of gcc now, and libstdc++
is part of that support.  Asking every ObjC++ programmer to order the C++ and
ObjC headers and #undef things just right seems quite error prone to me when we
can easily solve the problem once and for all.

// C++ includes
#include <list>
#include <vector>

// Obj C includes
#undef try
#undef catch
#import <Cocoa/Cocoa.h>
#import "my_header.h" 
#include <iostream>     // oops, put C++ header in wrong place!

int main()
{
//    ....
}

That is a customer-hostile solution.

-Howard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #15 from gdr at integrable-solutions dot net  2005-12-03 04:20 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #14 from hhinnant at apple dot com  2005-12-03 01:25 -------
| (In reply to comment #13)
| > Subject: Re:  exception_defines.h #defines try/catch
| > 
| > I'm saying that if you're intending to use try/catch and yet not
| > want what the mean in standard C++, nor what they would mean in GNU
| > C++ with -fno-exceptions, then you have to watch what you're doing.
| > Meaning, in your *own* codes, you #undef try/catch.  Whether it is in
| > Cocoa.h or foobar.c, I don't care.  Just take your responsability to
| > #undef them -- because you have decided to have mean something else.
| > I'm not inclined in seeing the libstdc++ be uglified in that direction.
| 
| I see, thanks for the clarification.
| 
| It is my understanding that gcc 4.1 supports a language called Obj C++. 

I don't think anybody is disputing that.  It is also a simple fact
that GCC documents what happens with -fno-exceptions.

 In
| this language (and I am by no means an Obj C++ expert) you can pretty much
mix
| & match Obj C and C++.  I have customers using Obj C++ who want to turn off
C++
| exception support, but retain Obj C exception support.  They can easily do so
| -- unless they include a libstdc++ header.  The libstdc++ headers are messing
| up their ObjC @try/@catch statements.  That is, libstdc++ is not supportive
of
| ObjC++ in this manner.

No. ObjC++ is messing with itself.  -fno-exceptions is documented.
Either you don't want to use it, and you don't.  Or you want to use it
and you have to abide by what it does.  

| They are not trying to use C++ try/catch in a bizarre or unsupported manner. 

Then, why what is this PR is about in the first place?
-fno-exceptions turns try/catch into macros with specified semantics.
If you don't like those semantics, either you don't use
-fno-exceptions, or redifine the macros to meet your needs.

[...]

| That is a customer-hostile solution.

Trying not to abide by the rules and getting back and shouting for
hostility is a joke.  A sad one, Howard :-(

Asking for more uglification in libstdc++ just to fix ObjC++ is a
hostile solutions, if "hostile" is found to be appropriate
qualification in this discussion.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #16 from hhinnant at apple dot com  2005-12-04 02:12 -------
(In reply to comment #15)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> I don't think anybody is disputing that.  It is also a simple fact
> that GCC documents what happens with -fno-exceptions.

I think it is good that gcc documents what it does, and I am also impressed
with the gcc documentation in general.  But just because something is
documented doesn't make it the best answer.  Thank you for letting me know this
behaivor is documented (I hadn't even tried to look that up, and still haven't
found it).  It is still a customer-hostile solution.

> Trying not to abide by the rules and getting back and shouting for
> hostility is a joke.  A sad one, Howard :-(

I'm not shouting (no caps, not even an exlamation point), but perhaps my
vocabulary needs explaining.  I'm a pretty simple guy.  And I'm also very
customer focused in everything I do (even in situations that are not
traditionally vendor/customer).  If a solution seems to work for customers very
well, I'll often call it customer-friendly.  If a solution seems to work for
customers very poorly, I'll often call it customer-hostile.  I'm not trying to
shout or make any jokes.  It is simply the way I work.  My apologies for not
explaining that up front.

But I won't apologize for being customer focused.  That focus has served me
well over the past two decades.  If I provide a service, and those who I'm
providing the service to don't find that service useful, I'll look inward first
- every single time.  I'll continue to think about solutions from the
customer's viewpoint as best I am able.  And if or when I ever find myself
having trouble doing that, I pray I'm able to retire.

> No. ObjC++ is messing with itself.

I don't know what that means.  Or even how it would be relevant.  ObjC++ is
what it is.  If you or I don't like ObjC++, is that relevant?

> Either you don't want to use it, and you don't.  Or you want to use it
> and you have to abide by what it does.  

Maybe it does the wrong thing.  We have customer complaints.

> Then, why what is this PR is about in the first place?

My bad for not explaining it better in the original post.

This PR is about the fact that although our customers find the compiler's
definition of -fno-exceptions useful, and want use it, but they find the
libstdc++'s reaction to this compiler flag unhelpful.  Furthermore, making
libstdc++'s behavior under -fno-exceptions to actually be useful for our
customers is nearly trivial.  Yes readability takes a minor hit.  But
functionality/usefulness increases.

I really don't even understand why this is controversial.  This is a minor
issue that will have absolutely no impact on our C++ customers, and will make
our ObjC++ customers much happier.  If someone had raised a point about how we
are harming our C++ customers with this fix, I would have been alarmed and
searched for a solution that didn't harm our C++ customers.  If it was a major
imposition from an implementation point of view, I would be alarmed.  But as it
is, all I'm hearing is that there is an objection to helping our ObjC++
customers at the expense of a very minor readability hit in libstdc++
internals.  I'm honestly very confused by that response.

-Howard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

------- Comment #17 from gdr at integrable-solutions dot net  2005-12-04 02:54 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| But I won't apologize for being customer focused.

Geeat!  And people disagreeing with you on this point are not necessary
customer unfocused.

[...]

| > No. ObjC++ is messing with itself.
| 
| I don't know what that means.  Or even how it would be relevant.  ObjC++ is
| what it is.  If you or I don't like ObjC++, is that relevant?

I'm quite disappointed you reduced this issue to liking/disliking ObjC++.
If you believe that is the appropriate reduction, this is my last
message on the issue.  The rest clarifies what I said earlier.

This issue has nothing to do with liking or disliking ObjC++, not
matter how much of "hostility" or other "emotion" you would like to
inject into it.  ObjC++ got it wrong, it got it wrong.  The place to
fix it is in ObjC++.  That has nothing to do with liking or disliking
ObjC++. 

[...]

| I'm honestly very confused by that response.

I would not guess that it is partly because you seem to approach the
issue only from ObjC++-centric point of view.  This is issue is not
just fixing ObjC++ by uglifying libstdc++.  Those macro definitions of
try/catch when -fno-exceptions have been there long before ObjC++ came
in.  It is not like we're suddenly changing them.  
The uglification you're proposing is also breaking interfaces:  All
user codes that worked with both -fexceptions and -fno-exceptions and
used try/catch now will break.  I don't think I'm prepared to accept
that breakage.  The fix is simple for ObjC++: #undef them if it thinks
it wants both -fno-exceptions, libstdc++ headers.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #18 from hhinnant at apple dot com  2005-12-04 15:55 -------
(In reply to comment #15)
> Subject: Re:  exception_defines.h #defines try/catch
> It is also a simple fact
> that GCC documents what happens with -fno-exceptions.

I'm trying to find this documentation.  So far all I've found is:

http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options

-fexceptions
Enable exception handling....

Is there more?

Thanks,
Howard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #19 from hhinnant at apple dot com  2005-12-06 01:19 -------
(In reply to comment #17)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | I don't know what that means.  Or even how it would be relevant.  ObjC++ is
> | what it is.  If you or I don't like ObjC++, is that relevant?
> 
> I'm quite disappointed you reduced this issue to liking/disliking ObjC++.
> If you believe that is the appropriate reduction, this is my last
> message on the issue.  The rest clarifies what I said earlier.

Message #16, starting with the paragaph:

> This PR is about the fact...

states what I think this issue reduces to.

> This issue has nothing to do with liking or disliking ObjC++, not
> matter how much of "hostility" or other "emotion" you would like to
> inject into it.

I'm sorry if you find my vocabulary offensive, even after I've politely
explained myself.  "customer-friendly" and "customer-hostile" are terms I've
used for a long time.  I find them self explanatory, to the point, and not
inflamatory.  Would "customer-friendly" and "not customer-friendly" work better
for you?  I'm certainly willing to change my vocabulary.

> ObjC++ got it wrong, it got it wrong.  The place to
> fix it is in ObjC++.  That has nothing to do with liking or disliking
> ObjC++. 

How did ObjC++ get it wrong?  And what is "it"?

> I would not guess that it is partly because you seem to approach the
> issue only from ObjC++-centric point of view.

<chuckle>  I would not guess that either, considering my background.  Indeed
I'm trying my best not to approach this from a C++ centric point of view.

> This is issue is not
> just fixing ObjC++ by uglifying libstdc++.  Those macro definitions of
> try/catch when -fno-exceptions have been there long before ObjC++ came
> in.  It is not like we're suddenly changing them.  
> The uglification you're proposing is also breaking interfaces:  All
> user codes that worked with both -fexceptions and -fno-exceptions and
> used try/catch now will break.  I don't think I'm prepared to accept
> that breakage.

Thank you for pointing me to our documentation.  We apparently do not document
the behavior you want to preserve.  Therefore we will not be breaking anything.
 If user code is using try/catch and -fno-exceptions at the same time, it is
doing so at its own peril.  Simply omitting a standard header from the
customer's code could change compiling code into non-compiling code.

#include <limits>  // breaks under -fno-excetions if this header is removed

void foo()
{
     try 
    {
         bar();
    }
    catch (...)
    {
    }
}

>  The fix is simple for ObjC++: #undef them if it thinks
> it wants both -fno-exceptions, libstdc++ headers.

If this fix were simple, then great.  But it isn't simple because each ObjC++
customer has to re-implement it, and not just in one place, but in every single
translation unit.  And it doesn't even work in general if ObjC++ headers can
contain @try/@catch and contain std::lib includes:

// C++ includes
#include <list>
#include <vector>

// Obj C includes
#undef try
#undef catch
#import "my_header.h"   // oops, my_header.h includes <iostream>!

That's a maintenance nightmare for the ObjC++ customer!  And the reason we put
the customer through this is so that we can read "try" instead of "__try" in
the libstdc++ implementation?

If we really wanted to fix this right, we'd get rid of 95% of the try/catch
clauses in the first place (via RAII techniques).  Then we wouldn't have to
read "try" or "__try" (except very rarely).

-Howard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[bkoz at gcc dot gnu dot org]

------- Comment #20 from bkoz at gcc dot gnu dot org  2005-12-07 19:01 -------
>  I have customers using Obj C++ who want to turn off C++
> exception support, but retain Obj C exception support.  [snip]

What does this even mean? Can you detail or explain how this is supposed to
work?

> They are not trying to use C++ try/catch in a bizarre or unsupported manner.
> They are simply trying to use ObjC++ exceptions without the unwanted cost of
> C++ exceptions.

IMHO, yes, this is completely misguided, unsupported, bizarre, known to fail,
and should be documented as such.

If you are going to go through and add in hacks to deal with -fno-exceptions
for every C++/X language combo, then I'd be in favor of -fno-exceptions be
changed so that the C++ FE takes care of the keywords, since at least then
it'll all be taken care of in one place and would be consistently well-defined.
I think that's the proper place to fix this.

Can you point out where Objective C++ -fno-exceptions behavior documented?

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2005-12-13 20:03 -------
One more thing is that this is not documented anywhere (I can find) that
libstdc++ does this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #22 from hhinnant at apple dot com  2006-01-11 15:30 -------
Conforming C++ programs exist that work correctly with -fno-exceptions as long
as they don't include any libstdc++ header.  These same programs can fail (at
either compile time or run time) if they also include some (not all) libstdc++
header.

For example:

#include <stdio.h>

#define glue(a, b)  a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW     "hello"
#define LOW         LOW ", world"

int main()
{
    printf("%s\n", xglue(try, LOW));
}

This is a conforming C++ program.  It should run and print out:

hello, world

And it does so for gcc whether or not -fno-exceptions.

However if the same program includes <vector> or <iostream> (just as an
example), then the program runs only if -fno-exceptions is not specified. 
Otherwise:

/Volumes/Data/Development/XcTest/main.cpp:12:1: error: pasting ")" and "LOW"
does not give a valid preprocessing token
/Volumes/Data/Development/XcTest/main.cpp: In function 'int main()':
/Volumes/Data/Development/XcTest/main.cpp:12: error: expected
primary-expression before 'if'

#define'ing try and catch is non-conforming.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at cs dot tamu dot edu]

------- Comment #23 from gdr at cs dot tamu dot edu  2006-01-11 15:56 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| #define'ing try and catch is non-conforming.

You forgot to mentin that -fno-exceptions is neither mandated, nor
required to work with programs that play tricks with try/catch.
So, your assertion is unfounded.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #24 from hhinnant at apple dot com  2006-01-11 16:10 -------
(In reply to comment #23)
> You forgot to mentin that -fno-exceptions is neither mandated, nor
> required to work with programs that play tricks with try/catch.
> So, your assertion is unfounded.

The demo program does not play tricks with try/catch.  It uses the identifier
"try" in a completely conforming manner.

What subset of C++ programs do we expect to work under -fno-exceptions?  And
where is that documented?  The only thing I can find in our documentation that
addresses my question is:

>You may also wish to disable this option if you are compiling older
>C++ programs that don't use exception handling. 

My demo is exactly that:  A C++ program that does not use exception handling
(and yet is still conforming).  And gcc (without libstdc++) handles it just
fine.

Where do we document that some, but not all libstdc++ headers change the
semantics of -fno-exception (as gcc documents it) and may render some
conforming C++ programs broken?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at cs dot tamu dot edu]

------- Comment #25 from gdr at cs dot tamu dot edu  2006-01-11 16:41 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #24 from hhinnant at apple dot com  2006-01-11 16:10 -------
| (In reply to comment #23)
| > You forgot to mentin that -fno-exceptions is neither mandated, nor
| > required to work with programs that play tricks with try/catch.
| > So, your assertion is unfounded.
| 
| The demo program does not play tricks with try/catch.

It does, with xlgue(try, ....).


| What subset of C++ programs do we expect to work under -fno-exceptions?

Those that understand that try/catch are special.

[...]

| >You may also wish to disable this option if you are compiling older
| >C++ programs that don't use exception handling. 
| 
| My demo is exactly that:  A C++ program that does not use exception handling
| (and yet is still conforming).

Can you provide standard specs that says the program must work with
-fno-exceptions?

| Where do we document that some, but not all libstdc++ headers change the
| semantics of -fno-exception (as gcc documents it) and may render some
| conforming C++ programs broken?

If the issue is that -fno-exceptions is not well documented, then we
should document it better.  I'm happy to review documentation patches
that reflect the current state. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #26 from hhinnant at apple dot com  2006-01-11 18:02 -------
(In reply to comment #25)
> Subject: Re:  exception_defines.h #defines try/catch
> | The demo program does not play tricks with try/catch.
> 
> It does, with xlgue(try, ....).

No, "try" in this context is not a keyword.  There is no try, no catch, no
exception, in this conforming C++ program.

> | What subset of C++ programs do we expect to work under -fno-exceptions?
> 
> Those that understand that try/catch are special.

The intent of turning off exception handling in the compiler is to accomidate
programs that are ignorant of try/catch, and have no need to process
exceptions.

> Can you provide standard specs that says the program must work with
> -fno-exceptions?

Of course not.  Does this imply that we ought to lower our expectations of our
product when exceptions are disabled such that it will seemingly randomly break
conforming code?  Or are our quality standards higher than that?

> | Where do we document that some, but not all libstdc++ headers change the
> | semantics of -fno-exception (as gcc documents it) and may render some
> | conforming C++ programs broken?
> 
> If the issue is that -fno-exceptions is not well documented, then we
> should document it better.  I'm happy to review documentation patches
> that reflect the current state. 

I would rather not document that the libstdc++ takes a position contrary to the
compiler and does not work with exception-ignorant but conforming code with
-fno-exceptions.  Such a position would be hard to justify.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at cs dot tamu dot edu]

------- Comment #28 from gdr at cs dot tamu dot edu  2006-01-12 00:12 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #26 from hhinnant at apple dot com  2006-01-11 18:02 -------
| (In reply to comment #25)
| > Subject: Re:  exception_defines.h #defines try/catch
| > | The demo program does not play tricks with try/catch.
| > 
| > It does, with xlgue(try, ....).
| 
| No, "try" in this context is not a keyword.

I did not say it was a keyword.  I know what it is in that phase.

try/catch are special when -fno-exceptions.

[...]

| > Can you provide standard specs that says the program must work with
| > -fno-exceptions?
| 
| Of course not.

Then stop claiming that your use was conformant.

[...]

| I would rather not document that the libstdc++ takes a position
| contrary to the compiler

It does not take a position contrary to the compiler.  It complements
the compiler, with its own additional requirement.  That is not new.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at cs dot tamu dot edu]

------- Comment #27 from gdr at cs dot tamu dot edu  2006-01-12 00:12 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Or are our quality standards higher than that?

The way you solve this is neither through rhetorics, neither as a
libstdc++ PR.  The way you solve this is to make the front-end complete
-- try/catch are special with -fno-exceptions.  Really.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #29 from hhinnant at apple dot com  2006-01-12 00:59 -------
(In reply to comment #28)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> | No, "try" in this context is not a keyword.
> 
> I did not say it was a keyword.  I know what it is in that phase.
> 
> try/catch are special when -fno-exceptions.

In the preprocess stage, try/catch are not special when -fno-exceptions
according to the compiler.  They are only special at this stage according to
libstdc++, and for no reason I find convincing.

> | > Can you provide standard specs that says the program must work with
> | > -fno-exceptions?
> | 
> | Of course not.
> 
> Then stop claiming that your use was conformant.

*No* program is conformant if it uses -fno-exceptions (by definition).  I'm
claiming that this demo is conforming if it does not use -fno-exceptions.  I'm
also claiming that it does not use the C++ try, catch, or throw, and therefore
is an excellent candidate to work correctly under -fno-exceptions.

> | I would rather not document that the libstdc++ takes a position
> | contrary to the compiler
> 
> It does not take a position contrary to the compiler.  It complements
> the compiler, with its own additional requirement.  That is not new.

The mere inclusion of <vector> breaks the conforming C++ program (under
-fno-excepttions).

#include <stdio.h>
#include <vector>

#define glue(a, b)  a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW     "hello"
#define LOW         LOW ", world"

int main()
{
    printf("%s\n", xglue(try, LOW));
}

I realize that once the customer specifies -fno-exceptions, all bets are off. 
Nothing has to work.  Not g++, not libstdc++.  But there has obviously been
effort to make g++ and libstdc++ work under this environment.  I'm simply
pointing out that the effort could be improved.  Obviously no standard is going
to back this view up.

We have a conforming C++ program, which does not use try/catch/throw, which
works as expected under -fno-exceptions if you don't include <vector>, and
breaks if you do.  I think libstdc++ can and should do better than that.  We
have customer complaints on this issue.  I'm developing a library-based patch
to improve our support in this area.

> The way you solve this is to make the front-end complete

If you want to lead an effort to improve support of this issue in the front
end, that sounds really good to me.  Please do.  Note that this solution will
still involve libstdc++ being changed to not #define try and catch (which is
the fundamental problem).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at cs dot tamu dot edu]

------- Comment #30 from gdr at cs dot tamu dot edu  2006-01-12 01:10 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #28)
| > Subject: Re:  exception_defines.h #defines try/catch
| > 
| > | No, "try" in this context is not a keyword.
| > 
| > I did not say it was a keyword.  I know what it is in that phase.
| > 
| > try/catch are special when -fno-exceptions.
| 
| In the preprocess stage, try/catch are not special when -fno-exceptions
| according to the compiler.

They are for libstdc++.  You can debate at length.  You won't change
that fundamental fact.  However, you'll make progress, when you
recognize that and solve the problem where it should be.

[...]

| I realize that once the customer specifies -fno-exceptions, all bets
| are off.  

Great.  Fix the problem in the front-end.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at cs dot tamu dot edu]

------- Comment #31 from gdr at cs dot tamu dot edu  2006-01-12 01:15 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| I'm simply pointing out that the effort could be improved.
| Obviously no standard is going to back this view up.

Great.  Then stopping making conformance claims.  Also consider the
suggestion made earlier that the root of the problem is elsewhere --
extend the front-end to be complete.

| We have a conforming C++ program, which does not use try/catch/throw, 

it uses the identifier "try".

| which
| works as expected under -fno-exceptions if you don't include <vector>, and
| breaks if you do.  I think libstdc++ can and should do better than that.  We
| have customer complaints on this issue.  I'm developing a library-based patch
| to improve our support in this area.

given than bkoz and I have already expressed our suggestion of no
further uglification of libstdc++, I'm waiting to see how the
library-based patch would look like.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at physics dot uc dot edu]

------- Comment #32 from pinskia at gcc dot gnu dot org  2006-01-12 01:26 -------
Subject: Re:  exception_defines.h #defines try/catch


On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote:
> | I realize that once the customer specifies -fno-exceptions, all bets
> | are off.
>
> Great.  Fix the problem in the front-end.

As I said before, there is still a diagnostic issue and now it is worse 
with
doing that in the front-end since people don't read docs that well so 
we will
be getting bug reports about try/catch not doing the correct thing when
-fno-exceptions is supplied (yes I am serious).


-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

Re: [Bug libstdc++/25191] exception_defines.h #defines try/catch

[Andrew Pinski]

On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote:
> | I realize that once the customer specifies -fno-exceptions, all bets
> | are off.
>
> Great.  Fix the problem in the front-end.

As I said before, there is still a diagnostic issue and now it is worse 
with
doing that in the front-end since people don't read docs that well so 
we will
be getting bug reports about try/catch not doing the correct thing when
-fno-exceptions is supplied (yes I am serious).


-- Pinski

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #33 from hhinnant at apple dot com  2006-01-12 02:49 -------
(In reply to comment #32)
> As I said before, there is still a diagnostic issue and now it is worse 
> with
> doing that in the front-end since people don't read docs that well so 
> we will
> be getting bug reports about try/catch not doing the correct thing when
> -fno-exceptions is supplied (yes I am serious).

Yes, excellent point.  Let's back up a minute:

What do we want to happen for this program (under -fno-exceptions)?

int main()
{
    try
    {
    }
    catch (...)
    {
    }
}

?

My recommendation would be something along the lines of:

error: exception handling disabled, use -fexceptions to enable

(which is what currently happens, good job all around).

Now:  what do we want to happen for this program:

#include <vector>

int main()
{
    try
    {
    }
    catch (...)
    {
    }
}

?

My recommendation:  Same as the last program.  Today's results:  Compiles with
no diagnostic.

I don't think this is the best quality that we can offer, mainly due to the
difference in behavior by merely including <vector>.

So it comes back to the first example:  What is the best solution for the
customer if try/catch is used with -fno-exceptions?  Perhaps I am wrong that an
error is best?  What do other compilers do in this situation?

EDG:

"ComeauTest.c", line 3: error: support for exception handling is disabled
      try
      ^

CodeWarrior:

Error   : exception handling option is disabled
HelloWorld.cp line 4    { 

If I'm wrong about a diagnostic being preferrable, I'm in good company.  And
both of these products give the same result if <vector> is included.

If there is to be a front end fix, it would have to be special for #pragma GCC
system_header.  Just seems like a lot of fuss just so you can read "try"
instead of "__try" in a libstdc++ header.  But I have no objection to someone
fixing the front end that way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[l dot lunak at suse dot cz]

------- Comment #34 from l dot lunak at suse dot cz  2007-04-24 10:54 -------
I think the reason why the discussion here is so complicated is that you
libstdc++ people are, because of exception_defines.h, confused about what
-fno-exceptions actually does. From comment #15: "Then, why what is this PR is
about in the first place? -fno-exceptions turns try/catch into macros with
specified semantics." That's clearly not true. It is libstdc++ that changes the
try/catch keywords into macros and _changes_ their semantics. Also, again from
comment #15: "It is also a simple fact that GCC documents what happens with
-fno-exceptions." - Sorry, but where? The info/man pages only say "You may also
wish to disable this option if you are compiling older C++ programs that don't
use exception handling.", but it doesn't say anything more about
-fno-exceptions.

What -fno-exceptions does (when libstdc++ is not used) is that it disables
exceptions support. If any code requiring exceptions support is actually used,
an error is generated (try compiling the testcase from comment #4 with
-fno-exceptions and without the <string> include). This is the same like when
asking for full ANSI compliance when compiling and using GNU extensions in the
code.

What libstdc++ does is that it (silently, to make it even worse) globally
changes the semantics of the try/catch keywords, preventing the compiler from
producing the error message and changing the behaviour of the compiled code,
which may lead to incorrect results.

Comment #2 also doesn't hold much of value, since if libstdc++ tries to be as
much conforming as possible, why does it change semantics of C++ keywords?
Also, if you argue against __try/__catch, why do you already use
__throw_exception_again, which is just a different name for throw? If you can
use this, you can as well use __try and __catch. Since try/catch can be
redefined, try and catch used in the libstdc++ code clearly are not the actual
normal C++ keywords.

Please do as the original comment says and use __try/__catch instead of
changing semantics of C++ keywords. What libstdc++ now does is very clearly a
bug. The severity of this bug should be also raised since this bug can silently
change code behaviour of any code using libstdc++.


-- 

l dot lunak at suse dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |l dot lunak at suse dot cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pcarlini at suse dot de]

------- Comment #35 from pcarlini at suse dot de  2007-04-27 10:04 -------
(In reply to comment #34)
> Also, if you argue against __try/__catch, why do you already use
> __throw_exception_again, which is just a different name for throw? If you can
> use this, you can as well use __try and __catch. Since try/catch can be
> redefined, try and catch used in the libstdc++ code clearly are not the actual
> normal C++ keywords.

I'm finding this, seemingly secondary, argument rather compelling. All in all,
I'm personally coming to the conclusion that we should implement the change
originally suggested by Howard, for many additional reasons, totally unrelated
to Objective C. In other terms, in that way -fno-exceptions would be much more
safe and much more useful, and, in any case, we would not be playing any trick
which we are not playing already (as explained above).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pcarlini at suse dot de]

------- Comment #36 from pcarlini at suse dot de  2007-04-27 12:04 -------
Humm, probably, however, I'm finally getting Gaby's point about the front-end
involvement (sorry, I wasn't really paying attention to this PR until a few
days ago): if we implement something like Howard's change we would certainly
solve many problems *but* we would regress in another area: some general user
code (thus freely using try/catch blocks) would not compile anymore when
-fno-exceptions is passed on the command line. I see why some people would not
consider that a problem, because they are removing by hand try/catch from
translation units not meant to use exceptions, but I consider that a defect
anyway, or, at least, a very substantive change of behavior which must be
seriously weighted. Instead, ideally, one would like to compile the *very same
code* and just not generate the heavy exception machinery when -fno-exceptions
is passed on the command line. I think that idea exists in the current design
of the macros, maybe incompletely implemented (e.g., at least one library
header must be included), and it's nice, very nice, by itself.

Now, that idea in principle it's perfectly doable, the only problem is that the
front-end must be changed, isn't something we can do completely at the library
level. Alternately, probably better in order not to break existing code, a new
option could be added, which, essentially, at variance with the current
-fno-exceptions, would parse try/catch normally, and then finally simply skip
the semantics.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #37 from hhinnant at apple dot com  2007-04-27 14:15 -------
Thanks for looking at this issue.

Also consider Andrew's point about useful diagnostics, for example from comment
#4.  And the followup to that point in #33 which includes field experience on
how other compilers deal with this same option.  I.e. from this viewpoint,
getting a compile time error when you use try/catch with -fnoexceptions is a
feature, not a bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pcarlini at suse dot de]

------- Comment #38 from pcarlini at suse dot de  2007-04-27 14:22 -------
(In reply to comment #37)
> Thanks for looking at this issue.
> 
> Also consider Andrew's point about useful diagnostics, for example from
> comment #4.

Of course, if/when the front-end is changed as I was outlining, diagnostic
would be emitted in such cases.

> And the followup to that point in #33 which includes field experience on
> how other compilers deal with this same option.  I.e. from this viewpoint,
> getting a compile time error when you use try/catch with -fnoexceptions is a
> feature, not a bug.

That would be a good argument for my last point: i.e., do not change the
semantics of -fno-exceptions, provide instead a new switch, which would be
different only in that the front-end would still accept syntactically exception
constructs, only would not emit semantics for those. *If* we have that switch,
then probably we could *additionally* change the library as you are suggesting,
that would provide a complete set of features to the users, in my opinion.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[l dot lunak at suse dot cz]

------- Comment #39 from l dot lunak at suse dot cz  2007-04-27 14:41 -------
I find the reasoning that this change should not be done because somebody
possibly might be using the libstdc++'s different semantics of try/catch rather
weak, for several reasons:
- it's not documented anywhere, at least I haven't found any such docs, so it's
internal undocumented feature
- if somebody actually uses it, then they can simply switch to __try/__catch
and be done with it; additionally compared to users who want normal try/catch
keywords they have the advantage that the compiler will detect the problem,
while with the current changed try/catch there's absolutely no detection
besides non-working code
- finally, I find it very unlikely that there actually would be people using
try/catch in the way libstdc++ does. You cannot "just not generate the heavy
exception machinery" and hope it works. Code that explicitly uses exceptions
relies on them, just like e.g. code using explicit NULL pointer checks relies
on them. You cannot silently remove all "if( pointer == NULL )" checks in code
and hope it works, because that would avoid error recovery code. The same way
silently dumping catch blocks means dumping error recovery code. Libstc++ can
work this way because it doesn't use exceptions on its own, it just has the
try/catch #defines to be able to work with code both using and not using them.
In general if somebody wants to write code not using exceptions they can simply
not use them. Special cases like libstdc++ are special and people doing that
should better known what they're doing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #40 from pinskia at gcc dot gnu dot org  2008-04-24 08:40 -------
*** Bug 36032 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc-bugzilla at contacts dot
                   |                            |eelis dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #41 from pinskia at gcc dot gnu dot org  2008-04-24 08:42 -------
>I'd rather you work around this in objective-c or objective c++.
Well guess what, it is more than an objective-c or objective C++ issue as PR
36032 had a good example for why, it can produce wrong code:
  #include <iostream>

  int main()
  {
    if(true) try {} catch(int) {}
    else std::cout << "bla\n";
  }


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[rguenth at gcc dot gnu dot org]

------- Comment #42 from rguenth at gcc dot gnu dot org  2008-06-02 11:48 -------
Can we please do something about this?  Either make -fno-exceptions
unconditionally always only execute the try block via frontend support (and not
only if you happen to include some libstdc++ header), or apply the suggested
fix of only fixing up the standard library and let user programs still using
exceptions when they specify -fno-exceptions error during compilation.

Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |blocker
           Keywords|                            |accepts-invalid, wrong-code
      Known to fail|4.1.3                       |4.1.3 4.3.0
   Last reconfirmed|2007-03-22 10:46:19         |2008-06-02 11:48:51
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #43 from paolo dot carlini at oracle dot com  2008-06-02 12:05 -------
Ok, I will just implement the __try / __catch suggestion. Hopefully the other
library maintainers will not disagree...


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[bkoz at gcc dot gnu dot org]

------- Comment #44 from bkoz at gcc dot gnu dot org  2008-06-02 20:20 -------
> Either make -fno-exceptions
> unconditionally always only execute the try block via frontend support (and not
> only if you happen to include some libstdc++ header)

This is my very strong preference. 

-fno-exceptions should be completely defined by cc1plus.

-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #45 from paolo dot carlini at oracle dot com  2008-06-02 20:59 -------
Frankly, at this point in the history of this issue, I don't have a strong
opinion. If we decide for the library-only solution, I can do it quickly, just
let me know.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
                   |dot com                     |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[bkoz at gcc dot gnu dot org]

------- Comment #46 from bkoz at gcc dot gnu dot org  2008-06-02 22:27 -------

To clarify, I would like to see this solution come into being:

1) -fno-exceptions
This flag turns off C++ exception handling support, which is indicated at
compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try,
catch, or throw produces an error. As a result, use of most C++ includes will
fail. 

2) -ftransform-exceptions 
This flag transforms the C++ language such that the keywords try, catch, and
throw change meaning. In particular, try blocks are executed "as if"
transformed into "if (true)", catch blocks are executed "as if" transformed
into "if (false)", and throw expressions are discarded. Although this will
compile C++ code that uses exceptions, please note that the resulting error
handling and code paths are decidedly different and is almost certainly not
what the original authors intended. 

At this point, exception_defines.h can just get junked, __throw_exception_again
mechanically changed into throw, documentation updated that reprobates that had
been happily using -fno-exceptions should just use -ftransform-exceptions, etc.
There will be bitching about this change of course, but separating out these
two things will be a blessing for GNU users.  

I believe this solution would fix the problem for all the various communities:

1) C++ purists who want to be able to use all the C++ keywords without
increasing levels of macro uglification
2) C hackers that want to write pseudo C++, or take existing C++ code and "run
it without exceptions"
3) C++ and ObjC++ people who want accurate diagnostics with and without
-fno-exceptions will get them. 

Perhaps this would solve Howard's issue with -fno-exceptions C++ code and
ObjC++ code that uses exceptions, but I don't really understand that issue. 

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[sebor at roguewave dot com]

------- Comment #47 from sebor at roguewave dot com  2008-06-02 23:08 -------
(In reply to comment #46)
[...]
> 2) -ftransform-exceptions 

should catch(X) expand into "else if (false)" rather than just "if (false)?"

That said, I don't think there is a way to do this using the preprocessor
alone. Consider that

    try { foo (); }
    catch (SomeException ex) {
        puts (ex.what ());
    }

will preprocess to:

    try { foo (); }
    if (false) {
        puts (ex.what ());   // <<< ex undefined
    }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[sebor at roguewave dot com]

------- Comment #48 from sebor at roguewave dot com  2008-06-03 00:07 -------
FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
in the C++ front end:

1. "try" is a no-op
2. "catch" blocks are syntax-checked but eliminated as dead code
3. "throw" checks to see if a user-defined handler is installed and if so,
   calls it with useful arguments (e.g., the what() string); if no handler
   is installed or if it returns, std::terminate() is called
4. function exception specification is diagnosed as a warning but otherwise
   ignored (libc, libsupc++, and libstdc++ header should compile cleanly)

libsupc++ provides a __set_xxx() function to let users install the handler.

AFAIK, IBM XLC++ implements 1, 2, and 4 when -qnoeh is used. Apache stdcxx
implements 3 for exceptions thrown by the library.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #49 from paolo dot carlini at oracle dot com  2008-06-03 09:52 -------
(In reply to comment #48)
> FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
> in the C++ front end:

FWIW, I find your suggestion very sensible and probably have already vaguely
hinted to something along these lines in the past. Then the PR is less and less
a library one and I'm afraid we have to strong arm a solid C++-front-end hacker
if we want to see progress in the near future...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[rguenther at suse dot de]

------- Comment #50 from rguenther at suse dot de  2008-06-03 10:00 -------
Subject: Re:  exception_defines.h #defines try/catch

On Tue, 3 Jun 2008, paolo dot carlini at oracle dot com wrote:

> ------- Comment #49 from paolo dot carlini at oracle dot com  2008-06-03 09:52 -------
> (In reply to comment #48)
> > FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
> > in the C++ front end:
> 
> FWIW, I find your suggestion very sensible and probably have already vaguely
> hinted to something along these lines in the past. Then the PR is less and less
> a library one and I'm afraid we have to strong arm a solid C++-front-end hacker
> if we want to see progress in the near future...

Well, can't we simply remove the libstdc++ #defines then and declare
libstdc++ unsupported for -fno-exceptions until the FE fixes it properly?

IMHO the libstdc++ #defines are clearly a bug.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #51 from paolo dot carlini at oracle dot com  2008-06-03 10:03 -------
(In reply to comment #50)
> Well, can't we simply remove the libstdc++ #defines then and declare
> libstdc++ unsupported for -fno-exceptions until the FE fixes it properly?
> 
> IMHO the libstdc++ #defines are clearly a bug.

Maybe, but a very, very old one ;) That said, if the other library maintainers
want that, I do not object.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[rguenth at gcc dot gnu dot org]

------- Comment #52 from rguenth at gcc dot gnu dot org  2008-09-22 12:40 -------
Can we please have

"1) -fno-exceptions
This flag turns off C++ exception handling support, which is indicated at
compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try,
catch, or throw produces an error. As a result, use of most C++ includes will
fail."

of comment #46 simply by the original suggestion, make the standard library
use __try and __catch and change libsupc++/exception_defines.h accordingly?
Appearantly the library wants to work without exception support, but this
support needs to be implemented in a way not messing with standard C++
keywords.

Note the frontend already undefines __EXCEPTIONS for -fno-exceptions:

>g++ -dD -E t.C | grep EXCE
#define __EXCEPTIONS 1
> g++ -dD -E t.C -fno-exceptions | grep EXCE

The frontend also produces an error if try or catch are used with
-fno-exceptions, but the _standard library implementation_ causes this
error do disappear(!)  Which is what this bug is about really.

It seems the library maintainers are not willing to see this problem.
Asking for a new C++ frontend feature as an excuse to not fix the
library problem is very lame IMHO.

So can we please - finally - do something about this?

Thank you very much.
Richard.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.1.3 4.3.0                 |4.1.3 4.3.0 4.4.0
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[rguenth at gcc dot gnu dot org]

------- Comment #53 from rguenth at gcc dot gnu dot org  2008-09-22 12:41 -------
CCing C++ FE maintainers.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot
                   |                            |org, mark at codesourcery
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #54 from paolo dot carlini at oracle dot com  2008-09-22 14:08 -------
(In reply to comment #52)
> It seems the library maintainers are not willing to see this problem.
> Asking for a new C++ frontend feature as an excuse to not fix the
> library problem is very lame IMHO.

For the record, speaking of myself, see Comments #43 and #45.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at gcc dot gnu dot org]

------- Comment #55 from jason at gcc dot gnu dot org  2008-09-23 20:43 -------
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions.  We don't need to error except on throw.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[l dot lunak at suse dot cz]

------- Comment #56 from l dot lunak at suse dot cz  2008-09-24 08:50 -------
(In reply to comment #55)
> It seems reasonable to me for try { X } catch... to mean X when
> -fno-exceptions.  We don't need to error except on throw.

It seems unreasonable to me that gcc would silently modify code's behaviour,
just like it would be unreasonable that -pedantic would silently change 'long
long i = 2LL << 34;' to 'long i = 0;'. With today's complex build systems it is
not that difficult to get -fno-exceptions without noticing and then get code
that works differently than intended (and I'm not making this up, I had such a
real case).
If people really want code with exception handling to work with both
-fexception states, then they need to write the code with that in mind and then
they can as well just use __try/__catch macros the way libstdc++ does now, just
without breaking the code for the rest of people who can run into trouble if
the compiler/libraries try to outguess them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[mark at codesourcery dot com]

------- Comment #57 from mark at codesourcery dot com  2008-09-24 13:03 -------
Subject: Re:  exception_defines.h #defines try/catch

jason at gcc dot gnu dot org wrote:
> ------- Comment #55 from jason at gcc dot gnu dot org  2008-09-23 20:43 -------
> It seems reasonable to me for try { X } catch... to mean X when
> -fno-exceptions.  We don't need to error except on throw.

We have to be careful, in some cases.  For example:

  extern int f();

  template <typename T>
  struct S {
    static int i;
  };
  template <typename T>
  int S<T>::i = f();

 int main() {
    try {
      return 0;
    } catch (...) {
      return S<int>::i;
    }
  }

This program, IIRC, is guaranteed to call "f", as a side-effect of the
presence of the catch-clause?  Of course, the C++ FE could still process
the "catch" clause; my only point is that we cannot literally just throw
away the catch clause.

I don't objection to -fno-exceptions silently discarding catch clauses,
as long as we avoid the kind of problem above.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at redhat dot com]

------- Comment #58 from jason at redhat dot com  2008-09-24 19:21 -------
Subject: Re:  exception_defines.h #defines try/catch

l dot lunak at suse dot cz wrote:
> ------- Comment #56 from l dot lunak at suse dot cz  2008-09-24 08:50 -------
> (In reply to comment #55)
>> It seems reasonable to me for try { X } catch... to mean X when
>> -fno-exceptions.  We don't need to error except on throw.
> 
> It seems unreasonable to me that gcc would silently modify code's behaviour,

The change I was talking about doesn't modify behavior.  If there are no 
exceptions, catch blocks will never be executed, so we can optimize them 
away in the presence of -fno-exceptions.

> This program, IIRC, is guaranteed to call "f", as a side-effect of the
> presence of the catch-clause?  Of course, the C++ FE could still process
> the "catch" clause; my only point is that we cannot literally just throw
> away the catch clause.

True, it would be more like { X } if (0) ...

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[l dot lunak at suse dot cz]

------- Comment #59 from l dot lunak at suse dot cz  2008-09-25 09:56 -------
(In reply to comment #58)
> >> It seems reasonable to me for try { X } catch... to mean X when
> >> -fno-exceptions.  We don't need to error except on throw.
> > 
> > It seems unreasonable to me that gcc would silently modify code's behaviour,
> 
> The change I was talking about doesn't modify behavior.  If there are no 
> exceptions, catch blocks will never be executed, so we can optimize them 
> away in the presence of -fno-exceptions.

But only in your perfect world. This bug and its silent discarding of exception
handling code (and an unintended -fno-exception from the build system) made us
release a broken package. If you want to add support for discarding of
explicitly written exceptions code, ok, whatever, but please make it explicit,
because having it the way it is with this bug is rather pointless (since then
either you don't use exceptions at all and then there's no need to write the
exception handling code, or you mix it and then you soon may find it simpler to
drop the -fno-exception rather than explicitly check all code paths after you
refactor something).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at redhat dot com]

------- Comment #60 from jason at redhat dot com  2008-09-26 21:57 -------
Subject: Re:  exception_defines.h #defines try/catch

l dot lunak at suse dot cz wrote:
> But only in your perfect world. This bug and its silent discarding of exception
> handling code (and an unintended -fno-exception from the build system) made us
> release a broken package.

-fno-exceptions is a big hammer.  It will break exceptions trying to 
pass through code compiled with that flag whether or not that code has 
any try/catch constructs.  If you might have some code that throws, you 
shouldn't use -fno-exceptions; that's what broke your package.  Getting 
an error on try would have helped you find that problem, but that 
doesn't mean it's the right answer for all situations; if I'm writing 
code that may be used by other programs, I should write it to be 
exception-safe even if I don't throw any exceptions myself.

Perhaps we could just warn once if we see try/catch outside library 
headers with -fno-exceptions.

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-06-02 11:48:51         |2008-11-18 18:45:35
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at gcc dot gnu dot org]

------- Comment #61 from jason at gcc dot gnu dot org  2008-11-19 21:42 -------
Created an attachment (id=16725)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16725&action=view)
Compiler patch to allow try/catch and rethrow under -fno-exceptions

I've attached a proposed patch to ignore try/catch/rethrow in the compiler with
a warning, which should make the libstdc++ header unnecessary.  Comments?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[l dot lunak at suse dot cz]

------- Comment #62 from l dot lunak at suse dot cz  2008-11-19 22:41 -------
(In reply to comment #60)
> -fno-exceptions is a big hammer.  It will break exceptions trying to 
> pass through code compiled with that flag whether or not that code has 
> any try/catch constructs.  If you might have some code that throws, you 
> shouldn't use -fno-exceptions; that's what broke your package.

 In that case I suggest you remove -fno-exceptions altogether, because it's
virtually impossibly for any non-trivial C++ application to make sure it
doesn't use any code that might throw, starting with operator new. Sorry, but
it's about as sensible argument as yours.

 Let me put it simply: -fno-exceptions is an optimization that saves generating
code that would not be used, in line with the C++ rule of not paying for what
one does not use. So it simply makes sense to use it in projects (or parts
thereof) that do no use exceptions in order to get some savings (does somebody
use -fno-exceptions in any other way?). Now, such code calls code from
elsewhere that may throw, and so the programmer uses also try-catch, but does
not actually test that specific part, since a) it's trivial code, b) he's too
busy and we're just people, c) getting an exception should be exceptional. And
we have perfectly fine code that compiles, but, when it eventually comes, does
not work. It may not happen in your perfect world but in the real one it does.

> Getting an error on try would have helped you find that problem, but that 
> doesn't mean it's the right answer for all situations;

 And what other situations are there, except for people who write code with
exception handling, who make sure it works even without exceptions, who are too
lazy to run sed few times, who will be explicitly aware of this and who
presumably will be just a handful of people in total compared to the rest?
What's the problem with giving these people -fstrip-exceptions or whatever and
leaving the rest as it is (with fixing libstdc++)?

> if I'm writing 
> code that may be used by other programs, I should write it to be 
> exception-safe even if I don't throw any exceptions myself.

 Irrelevant, this is the other way around.

> Perhaps we could just warn once if we see try/catch outside library 
> headers with -fno-exceptions.

 I'd love to live in your perfect world. Sadly, I don't, so I'm looking forward
to having to take care of code that will not have -Wexceptions in its flag
(since it needs to be explicitly enabled, right?) or where one warning will get
easily overlooked for whatever reason. I really fail to see what's so
complicated about not letting one shoot themselves in the foot just because of
lazy people with special needs. Thanks for trying, anyway.


-- 

l dot lunak at suse dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|l dot lunak at suse dot cz  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[rguenth at gcc dot gnu dot org]

------- Comment #63 from rguenth at gcc dot gnu dot org  2008-11-20 10:01 -------
The patch looks reasonable.  I understand that the warning is enabled by
default
but does not trigger from libstdc++ because that's system headers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #64 from paolo dot carlini at oracle dot com  2008-11-20 10:24 -------
(assuming I understand correctly Jason' approach - didn't really follow in
detail the thread, lately) let me know if you want me to remove the
exception_defines.h tricks from the library...


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at redhat dot com]

------- Comment #65 from jason at redhat dot com  2008-11-20 15:14 -------
Subject: Re:  exception_defines.h #defines try/catch

No, it doesn't make any sense to use try/catch in a program that you're 
planning to build with -fno-exceptions.  It does, however, make sense to 
use try/catch in a general purpose library that you want to work with 
exceptions enabled or disabled, such as libstdc++.

I believe Lubos is arguing that such libraries ought to use preprocessor 
tricks to accomplish this, but defining something like __try and __catch 
instead of try and catch.  The difference between this approach and my 
patch is that it requires the library writer to jump through hoops to 
make their code work with exceptions enabled and disabled.  I guess 
Lubos thinks this is good, that this is an unusual thing to want to do 
and so people that want to do it need to be very explicit about it so 
that people who don't want that but mistakenly build their code with 
-fno-exceptions get an error rather than a warning.

Anyone else have an opinion about this?

And yes, -Wexceptions is on by default in my patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

------- Comment #66 from hhinnant at apple dot com  2008-11-20 17:40 -------
(In reply to comment #65)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> No, it doesn't make any sense to use try/catch in a program that you're 
> planning to build with -fno-exceptions.  It does, however, make sense to 
> use try/catch in a general purpose library that you want to work with 
> exceptions enabled or disabled, such as libstdc++.
> 
> I believe Lubos is arguing that such libraries ought to use preprocessor 
> tricks to accomplish this, but defining something like __try and __catch 
> instead of try and catch.  The difference between this approach and my 
> patch is that it requires the library writer to jump through hoops to 
> make their code work with exceptions enabled and disabled.  I guess 
> Lubos thinks this is good, that this is an unusual thing to want to do 
> and so people that want to do it need to be very explicit about it so 
> that people who don't want that but mistakenly build their code with 
> -fno-exceptions get an error rather than a warning.
> 
> Anyone else have an opinion about this?
> 
> And yes, -Wexceptions is on by default in my patch.

I've tried really hard to just stay out of this one. :-)  I think Jason makes a
good argument.  However I just surveyed a bunch of my own code written to work
both with and without exceptions enabled, using "macro hoops".  In about 95% of
the cases transforming:

try
{
   X
} 
catch (Y)
{
   Z
}

to just:

X

is exactly what I want.  In the other 5% of the cases it is not.  In these
(relatively rare, but not uncommon) cases, the code under X gets transformed
into code that checks return values for error codes and acts on that error
code:

int er = X
if (er)
   return P

This scenario usually pops up when X is doing an allocation which throws when
exceptions are enabled and returns null when exceptions are disabled.

All that being said, is Jason's patch good or bad?  <shrug>  I'm still going to
have to manually design 100% of my try/catch clauses for exceptions enabled and
disabled.  If I don't, then I'll have a 5% bug rate even with Jason's patch. 
Part of me would prefer the error just to ensure that I haven't forgotten to
design for the exceptions-disabled case, even if that design would simply
translate to X.  Perhaps the warning will fill that role, I do not know.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[mmitchel at gcc dot gnu dot org]

------- Comment #67 from mmitchel at gcc dot gnu dot org  2008-11-20 17:55 -------
I think that the current libstdc++ behavior is undesirable, for the reasons
that Howard says.  In particular, the fact that including a libstdc++ header
can result in definitions of "try" and "catch" as macros is bad, even though,
of course, that happens only in the -fno-exceptions mode.  I find comments
about exceptions being a standard part of the language unpersuasive; while that
is of course true, G++ is certainly used by people who wan the "C++ without
exceptions" language and not supporting that well would put us at a competitive
disadvantage relative to other C++ compilers.

I think that changing libstdc++ to use __try, __catch, etc. is reasonable. 
That's certainly the approach used in other libraries.  However, I also think
Jason's patch is reasonable, provided of course that the documentation is
updated to reflect this new behavior.  

If I recall correctly, unwinding into a frame with no EH data will cause a
runtime abort, so programs will not silently skip catch clauses that have been
compiled away.  The program may fail, but at least it will not do so silently. 
Jason, is that correct?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at redhat dot com]

------- Comment #68 from jason at redhat dot com  2008-11-20 18:10 -------
Subject: Re:  exception_defines.h #defines try/catch

mmitchel at gcc dot gnu dot org wrote:
> If I recall correctly, unwinding into a frame with no EH data will cause a
> runtime abort, so programs will not silently skip catch clauses that have been
> compiled away.  The program may fail, but at least it will not do so silently. 
> Jason, is that correct?

Yes.  If the unwinder runs out of unwind info before it finds a handler, 
we call terminate().


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #69 from pinskia at gcc dot gnu dot org  2008-11-21 22:19 -------
I think this patch will not handle:
int main(void)
{
  try {
  }catch (int &a)
  {
    a = 1;
  }
}

-- CUT ---
In fact exception_defines.h's defines does not handle them correctly anyways.
I am working on a patch which adds -fignore-exceptions which has to be used
with -fno-exceptions which handles this correctly.  Plus we don't get erroneous
errors with -fno-exceptions now too.  Should -fignore-exceptions be default for
C++ when -fno-exceptions is used?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #70 from pinskia at gcc dot gnu dot org  2008-11-21 22:21 -------
Also my -fignore-exceptions calls __built_trap for a throw and make sure that
throw with an expression that the expression is evaluated.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #71 from pinskia at gcc dot gnu dot org  2008-11-21 22:23 -------
Created an attachment (id=16744)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16744&action=view)
My current patch for -fignore-exceptions

Note I have not added the testsuite part yet and this is based on 4.1.1 rather
than the trunk since I just happen to be working on this for the PS3 compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[pinskia at gcc dot gnu dot org]

------- Comment #72 from pinskia at gcc dot gnu dot org  2008-11-21 23:08 -------
Created an attachment (id=16745)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16745&action=view)
Updated patch with some testcases

Here is updated patch which allows more try/catch to work correctly without any
errors.  Plus it includes some testcases (sorry about the DOS line endings, and
about where the testcases are).  This again is against 4.1.1.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16744|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at redhat dot com]

------- Comment #73 from jason at redhat dot com  2008-11-23 00:02 -------
Subject: Re:  exception_defines.h #defines try/catch

pinskia at gcc dot gnu dot org wrote:
> I think this patch will not handle:
> int main(void)
> {
>   try {
>   }catch (int &a)
>   {
>     a = 1;
>   }
> }

Ah yes, I probably still need to push the declaration of a.

> I am working on a patch which adds -fignore-exceptions which has to be used
> with -fno-exceptions which handles this correctly.

This sounds like the wrong approach to me.  libstdc++ needs to work with 
or without -fno-exceptions, it shouldn't require another flag.  And I 
don't see the point in allowing 'throw expr;' under -fno-exceptions; I 
don't think the compiler can come up with another error reporting 
mechanism by itself.

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[jason at gcc dot gnu dot org]

------- Comment #74 from jason at gcc dot gnu dot org  2009-02-02 20:27 -------
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard proposed in the initial bug
report; it is inappropriate for library headers to redefine keywords.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[mark at codesourcery dot com]

------- Comment #75 from mark at codesourcery dot com  2009-02-02 20:29 -------
Subject: Re:  exception_defines.h #defines try/catch

jason at gcc dot gnu dot org wrote:

> Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
> fall back on the simpler solution that Howard proposed in the initial bug
> report; it is inappropriate for library headers to redefine keywords.

Makes sense to me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #76 from paolo dot carlini at oracle dot com  2009-02-02 21:11 -------
Ok, let's wait a couple of days and, assuming there are no objections, I
volunteer to implement that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[bonzini at gnu dot org]

------- Comment #77 from bonzini at gnu dot org  2009-02-03 17:10 -------
Can't the library just #undef try/catch at the end of each file that includes
exception_defines.h?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #78 from paolo dot carlini at oracle dot com  2009-02-03 17:14 -------
Nope, we never do that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[bonzini at gnu dot org]

------- Comment #79 from bonzini at gnu dot org  2009-02-03 17:15 -------
Yeah, but it seems better than uglifying __try/__catch all over the place...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #80 from paolo dot carlini at oracle dot com  2009-02-03 17:20 -------
Many solutions are better, in principle, but really this issue is too old.
After all we are uglifying also in other cases. Let's do that and be done with
it. Unless there are objections (or, better, constructive proposals, aka
patches) that the library solutions is an improvement.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo at gcc dot gnu dot org]

------- Comment #81 from paolo at gcc dot gnu dot org  2009-02-03 23:45 -------
Subject: Bug 25191

Author: paolo
Date: Tue Feb  3 23:44:53 2009
New Revision: 143913

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143913
Log:
2009-02-03  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/25191      
        * libsupc++/exception_defines.h: Depending on __EXCEPTIONS,
        deal consistently with __try and __catch too.
        * src/localename.cc: Replace try -> __try, catch -> __catch.
        * src/ios.cc: Likewise.
        * src/locale.cc: Likewise.
        * src/istream.cc: Likewise.
        * src/thread.cc: Likewise.
        * src/compatibility.cc: Likewise.
        * src/bitmap_allocator.cc: Likewise.
        * src/ios_init.cc: Likewise.
        * include/debug/deque: Likewise.
        * include/debug/list: Likewise.
        * include/tr1_impl/hashtable: Likewise.
        * include/std/bitset: Likewise.
        * include/ext/pb_ds/detail/resize_policy/
        hash_load_check_resize_trigger_imp.hpp: Likewise.
        * include/ext/pb_ds/detail/resize_policy/
        hash_standard_resize_policy_imp.hpp: Likewise.
        * include/ext/pb_ds/detail/cc_hash_table_map_/
        resize_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/cc_hash_table_map_/
        constructor_destructor_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/pat_trie_/
        split_join_branch_bag.hpp: Likewise.
        * include/ext/pb_ds/detail/pat_trie_/
        constructors_destructor_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/bin_search_tree_/
        constructors_destructor_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/gp_hash_table_map_/
        resize_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/gp_hash_table_map_/
        constructor_destructor_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/binary_heap_/
        constructors_destructor_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/binary_heap_/
        erase_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/binary_heap_/
        split_join_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/left_child_next_sibling_heap_/
        constructors_destructor_fn_imps.hpp: Likewise.
        * include/ext/pb_ds/detail/debug_map_base.hpp: Likewise.
        * include/ext/pb_ds/detail/list_update_map_/
        constructor_destructor_fn_imps.hpp: Likewise.
        * include/ext/slist: Likewise.
        * include/ext/memory: Likewise.
        * include/ext/rc_string_base.h: Likewise.
        * include/ext/ropeimpl.h: Likewise.
        * include/ext/vstring.tcc: Likewise.
        * include/ext/rope: Likewise.
        * include/ext/sso_string_base.h: Likewise.
        * include/bits/shared_ptr.h: Likewise.
        * include/bits/stl_list.h: Likewise.
        * include/bits/locale_classes.tcc: Likewise.
        * include/bits/locale_facets.tcc: Likewise.
        * include/bits/locale_classes.h: Likewise.
        * include/bits/forward_list.h: Likewise.
        * include/bits/stl_vector.h: Likewise.
        * include/bits/stl_deque.h: Likewise.
        * include/bits/istream.tcc: Likewise.
        * include/bits/stl_uninitialized.h: Likewise.
        * include/bits/ostream.tcc: Likewise.
        * include/bits/vector.tcc: Likewise.
        * include/bits/stl_tempbuf.h: Likewise.
        * include/bits/deque.tcc: Likewise.
        * include/bits/basic_string.tcc: Likewise.
        * include/bits/ostream_insert.h: Likewise.
        * include/bits/locale_facets_nonio.tcc: Likewise.
        * include/bits/stl_tree.h: Likewise.
        * include/bits/fstream.tcc: Likewise.
        * include/tr1/shared_ptr.h: Likewise.
        * include/tr1/hypergeometric.tcc: Likewise.
        * include/backward/hashtable.h: Likewise.
        * libsupc++/exception_ptr.h: Likewise.
        * libsupc++/eh_personality.cc: Likewise.
        * libsupc++/eh_call.cc: Likewise.
        * config/locale/gnu/monetary_members.cc: Likewise.
        * config/locale/gnu/time_members.h: Likewise.
        * config/locale/generic/time_members.h: Likewise.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/locale/generic/time_members.h
    trunk/libstdc++-v3/config/locale/gnu/monetary_members.cc
    trunk/libstdc++-v3/config/locale/gnu/time_members.h
    trunk/libstdc++-v3/include/backward/hashtable.h
    trunk/libstdc++-v3/include/bits/basic_string.tcc
    trunk/libstdc++-v3/include/bits/deque.tcc
    trunk/libstdc++-v3/include/bits/forward_list.h
    trunk/libstdc++-v3/include/bits/fstream.tcc
    trunk/libstdc++-v3/include/bits/istream.tcc
    trunk/libstdc++-v3/include/bits/locale_classes.h
    trunk/libstdc++-v3/include/bits/locale_classes.tcc
    trunk/libstdc++-v3/include/bits/locale_facets.tcc
    trunk/libstdc++-v3/include/bits/locale_facets_nonio.tcc
    trunk/libstdc++-v3/include/bits/ostream.tcc
    trunk/libstdc++-v3/include/bits/ostream_insert.h
    trunk/libstdc++-v3/include/bits/shared_ptr.h
    trunk/libstdc++-v3/include/bits/stl_deque.h
    trunk/libstdc++-v3/include/bits/stl_list.h
    trunk/libstdc++-v3/include/bits/stl_tempbuf.h
    trunk/libstdc++-v3/include/bits/stl_tree.h
    trunk/libstdc++-v3/include/bits/stl_uninitialized.h
    trunk/libstdc++-v3/include/bits/stl_vector.h
    trunk/libstdc++-v3/include/bits/vector.tcc
    trunk/libstdc++-v3/include/debug/deque
    trunk/libstdc++-v3/include/debug/list
    trunk/libstdc++-v3/include/ext/memory
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/constructors_destructor_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/erase_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/split_join_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/constructor_destructor_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/resize_fn_imps.hpp
    trunk/libstdc++-v3/include/ext/pb_ds/detail/debug_map_base.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/resize_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/left_child_next_sibling_heap_/constructors_destructor_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/constructor_destructor_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/split_join_branch_bag.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_standard_resize_policy_imp.hpp
    trunk/libstdc++-v3/include/ext/rc_string_base.h
    trunk/libstdc++-v3/include/ext/rope
    trunk/libstdc++-v3/include/ext/ropeimpl.h
    trunk/libstdc++-v3/include/ext/slist
    trunk/libstdc++-v3/include/ext/sso_string_base.h
    trunk/libstdc++-v3/include/ext/vstring.tcc
    trunk/libstdc++-v3/include/std/bitset
    trunk/libstdc++-v3/include/tr1/hypergeometric.tcc
    trunk/libstdc++-v3/include/tr1/shared_ptr.h
    trunk/libstdc++-v3/include/tr1_impl/hashtable
    trunk/libstdc++-v3/libsupc++/eh_call.cc
    trunk/libstdc++-v3/libsupc++/eh_personality.cc
    trunk/libstdc++-v3/libsupc++/exception_defines.h
    trunk/libstdc++-v3/libsupc++/exception_ptr.h
    trunk/libstdc++-v3/src/bitmap_allocator.cc
    trunk/libstdc++-v3/src/compatibility.cc
    trunk/libstdc++-v3/src/ios.cc
    trunk/libstdc++-v3/src/ios_init.cc
    trunk/libstdc++-v3/src/istream.cc
    trunk/libstdc++-v3/src/locale.cc
    trunk/libstdc++-v3/src/localename.cc
    trunk/libstdc++-v3/src/thread.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[paolo dot carlini at oracle dot com]

------- Comment #82 from paolo dot carlini at oracle dot com  2009-02-03 23:46 -------
Fixed for 4.4.0.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191