------- 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

Reply via email to