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

l dot lunak at suse dot cz gcc-bugzilla@gcc.gnu.org
Wed Nov 19 22:43:00 GMT 2008



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



More information about the Gcc-bugs mailing list