This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/25191] exception_defines.h #defines try/catch
- From: "hhinnant at apple dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Jan 2006 18:02:05 -0000
- Subject: [Bug libstdc++/25191] exception_defines.h #defines try/catch
- References: <bug-25191-11686@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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