[Bug 256642] New: STL redefines try and catch keywords
https://bugzilla.novell.com/show_bug.cgi?id=256642 Summary: STL redefines try and catch keywords Product: openSUSE 10.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: pth@novell.com ReportedBy: llunak@novell.com QAContact: qa@suse.de CC: dmueller@novell.com == testcase == #include <memory> void bar(); struct Foo; bool test() { try { bar(); } catch (Foo&) { return false; } return true; } == testcase == This testcase compiles without an error when compiled with -fno-exceptions, even though clearly it should not. The reason is /usr/include/c++/4.1.2/exception_defines.h which globally changes the keywords. Since compiling with exceptions has some costs associated, it makes sense to compile with -fno-exceptions and explicitly enable exceptions only for source that actually needs it. However, including any STL header effectively breaks this approach, as such places won't be found due to the missing compiler error. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #1 from dmueller@novell.com 2007-03-22 06:20 MST ------- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 matz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|matz@novell.com |pcarlini@novell.com ------- Comment #2 from matz@novell.com 2007-04-18 13:20 MST ------- Perhaps Paolo is interested to do something about this, despite Gabys thinkheadedness. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #3 from pcarlini@novell.com 2007-04-21 17:55 MST ------- I see, but I think this issue isn't exactly the same as libstdc++/25191: in other terms, if we were to implement Howard' proposal in that report, as far as I can see we would *not* resolve this one. Constructive suggestions? (besided thrashing completely the very idea of exceptions_defines.h, definitely controversial: in that case people arguing for it should post a message to libstdc++-v3 and clearly explain the issue). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #4 from pcarlini@novell.com 2007-04-21 18:35 MST ------- An additional remark: unless we are able to figure out a clean, uncontroversial plan for this issue, I would rather fiddle as little as possible with the throw/catch(es) in the library: I'm under the impression that we are close to implement some of Jason Merrill' ideas for finally fixing the C++ exception mechanism vs thread-cancellation, I would say, better avoid conflicts... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #5 from llunak@novell.com 2007-04-23 07:03 MST ------- It is the same as the upstream bug, at least as far as the origin of the problem is concerned: libstdc++ globally changing C++ keywords. And I also don't see a single problem with the suggested fix, i.e. libstdc++ using e.g. __try/__catch instead of the C++ keywords. It wouldn't break code outside of libstdc++ and libstdc++ itself already has one such #define (throw = __throw_exception_again) right next to it (which makes comment #2 in the upstream report rather ridiculous). Just run s/try/__try/ s/catch/__catch/ through libstdc++ sources and that's it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #6 from pcarlini@novell.com 2007-04-23 08:36 MST ------- I disagree: after s/try/__try/ s/catch/__catch/, if one compiles with -fno-exceptions the code in the Description above would still compile, right? What counts is that upon -fno-exceptions those __try and __catch(X) become 'if (true)' and 'if (false)' anyway. In any case, I'm not going to battle with Gaby about this issue, trying to do that made my life orrible in the past. Full stop. If we want something only for a SUSE branch, just let me know, no problem at all. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #7 from llunak@novell.com 2007-04-23 14:07 MST ------- No, the code in description fails to compile with -fno-exceptions _iff_ there's no STL include. It silently compiles in the case of using STL because STL changes try/catch keywords. If STL used e.g. __try/__catch, then the code in description won't be affected and will still fail as it should. Am I missing something important? Because I fail to see why there needs to be such a long discussion about something so trivial :(. If you can't get this fixed upstream for whatever obscure reason please fix this at least for us[*]. We released a broken update for one package and failed to notice it because of this bug. [*] The fix should be just first running this over all sources === sed 's/\btry\b/__try/g' sed 's/\bcatch\b/__catch/g' === and changing exception_defines.h like this: === #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 catch # define __throw_exception_again throw #endif === -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #8 from pcarlini@novell.com 2007-04-23 17:23 MST ------- (In reply to comment #7)
No, the code in description fails to compile with -fno-exceptions _iff_ there's no STL include. It silently compiles in the case of using STL because STL changes try/catch keywords. If STL used e.g. __try/__catch, then the code in description won't be affected and will still fail as it should.
Oops, sorry, now I see: it's just that I'm working on the library only and the library only for too much time, without seeing user code. Now I see what you mean, user code, as in Description above would be ok in that case. Therefore we are back to the basic issue: do we want to change the library as suggested in libstdc++/25191? If we want to do that "upstream", then someone (not me) has to convince Gaby. Otherwise, for a SUSE branch, we can run your sed command and change exception_defines.h, I have no objections, can also take care of that, just let me know. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
From comment #15 in upstream: "Then, why what is this PR is about in the first
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #9 from llunak@novell.com 2007-04-24 03:30 MST ------- I'd prefer if this was fixed upstream, as this is clearly a bug. My guess at why it is so difficult to explain in the upstream bugreport is because you libstdc++ people go too much used to this and don't know what -fno-exceptions really does. place? -fno-exceptions turns try/catch into macros with specified semantics." - This is not true. It's libstdc++ that turns the keywords into macros, with semantics that may be fine for libstdc++ but that are dangerous in general (as with our update). Using -fno-exceptions on its own disables exceptions support and if it is used anywhere in the code it aborts the compilation with an error message (just like e.g. if you asked for strict ANSI compliance and used GNU extensions). You can see the difference if you compile the testcase with -fno-exceptions and either leave or remove the "#include <memory>". Libstdc++ silently changes semantics of the C++ keywords. I'll try to sum this up in the upstream report, but if this is not enough to convince upstream, please do so for us. As far as I can say the upstream suggestion for the fix is the same like mine (mine actually has a bug in "define __catch catch", it should be "#define __catch(X) catch(X)"). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #10 from pcarlini@novell.com 2007-04-24 13:10 MST ------- Thanks Lubos for adding some comments to the audit trail. Really, I'm certainly with you, actually I was already with Howard when he filed the original report (I'm not sure whether there is a public trace of this), but fighting alone a battle against Gaby scares me totally, as I already said: generally, as a maintainer, I'm rather free to do whatever I want, but officially, even if is not doing much these days, Gaby is also a maintainer and when, once in a year average, decides that is against something and jumps in, things become really, really, painful. Anyway, as soon as I'm done with a couple other things, I will flank you, on the upstream issue. One suggestion, about Gaby: please be calm, very calm, stay to the technical issue, disregard any personal attack, do not reply to those, it's pointless. About fixing the issue for SUSE only, finally, I repeat, that I would be happy to take care of it, but I'm a bit scared by the consequences: such a large scale change implies that all the following merges will become harder... Now are trivial instead, we are by and large in sync. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 pcarlini@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=256642 Philipp Thomas <pth@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rguenther@novell.com | AssignedTo|pth@novell.com |rguenther@novell.com Status|ASSIGNED |NEW -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=256642 Richard Guenther <rguenther@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Priority|P5 - None |P4 - Low -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=256642 User rguenther@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=256642#c12 Richard Guenther <rguenther@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |UPSTREAM --- Comment #12 from Richard Guenther <rguenther@novell.com> 2009-01-15 02:11:40 MST --- Upstream tracks this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com