[Bug libstdc++/25191] exception_defines.h #defines try/catch
-- 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
--- 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
--- 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
--- 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
--- 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
--- 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=gccview=revrev=143913 Log: 2009-02-03 Paolo Carlini paolo.carl...@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
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=16744action=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
--- 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=16745action=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=16725action=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
--- 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
-- 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
--- 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
--- 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
--- 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
--- 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 ST::i = f();
int main() {
try {
return 0;
} catch (...) {
return Sint::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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
Re: [Bug libstdc++/25191] 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
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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
--- 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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
--- 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|-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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] writes: | (In reply to comment #8) | Subject: Re: exception_defines.h #defines try/catch | | hhinnant at apple dot com [EMAIL PROTECTED] 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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
