I have recently been able to put in a few hours toward my restrictive
exception specification warning mechanic.
I have it warning me correctly on very basic regular code with throw,
try/catch, function calls and exception specifications.
It's also activated by -Wres (restrictive exception specification) and
if it's not activated it has virtually no impact (only one if
statement per "interesting" token, such as a "throw" keyword token).
It doesn't yet work for:
- Templates.
- Function pointers.
- Non-explicit function calls, e.g. operators, con/destructors, casts.
Here's an example that does work:
=================================
test.cpp
=================================
class A {};
void foo() throw(int);
void bar() throw(A);
void zug();
void bam() throw(bool)
{
try
{
foo();
}
catch(int) {}
bar();
throw 1.0f;
throw false;
}
void zep() throw(int)
{
zug();
}
=================================
g++-res -c test.cpp -Wres
=================================
test/test.cpp: In function 'void bam()':
test/test.cpp:6: warning: RES: 'void bam() throw(bool)' may terminate
due to the following uncaught types being thrown:
test/test.cpp:13: warning: RES: 'A' thrown here by 'void bar()'.
test/test.cpp:3: warning: RES: where 'void bar()' is declared here.
test/test.cpp:14: warning: RES: 'float', thrown explicitly here.
test/test.cpp: In function 'void zep()':
test/test.cpp:18: warning: RES: 'void zep() throw (int)' has an
exception specification, yet it calls 'void zug()' which may throw
anything.
=================================
I have a few of questions:
1) I'm building TREE_LISTs of types for my internal exception lists
since I needs a bit more functionality than the existing exception
specification structure offers.
I'm using tree_cons() to build my tree nodes.
I use 1 node per thrown type per try/catch block, discardable once the
parser exits the try/catch block
How do I clean up my nodes when I'm done? Should I be manually freeing these?
2) I'm pretty sure that function pointers do not have their associated
exception specification, although the C++ standard requires that this
specification be compared when assigning to function pointers.
This is GCC bug 38069/12255: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38069
It looks as if nobody ever attempted making GCC comply with 15.4.3.
I guess nobody's in the process of fixing this? The bug's unassigned.
Is anyone likely to pick up this bug in the recent future?
3) I am adding a blacklist/whitelist mechanism for preventing calls to
functions declared in certain files being checked so that the warnings
don't become excessive. I was thinking of using:
-Wres-bl=<FILES>, Wres-wl=<FILES>
where <FILES> is a list of files enclosed by either <> or ""
(depending on path-type) with paths, hopefully wildcard-able.
eg: -Wres-wl=<*>"cp/*""cgraph.h" -Wres-bl="cp/decl.h" wouldn't check
declarations inside any <> includes, "cgraph.h", or anything inside
"cp/" except for "cp/decl.h"
I think there's a mechanism for suppressing warnings already (although
I had a brief glance now and didn't see it), but unfortunately I need
to suppress the warnings based on the call-target location not the
warning location, and I also need to know whether a call is warn-able
far in advance of issuing the warning.
The questions are:
3a) Is there a better or more consistent way to specify a
whitelist/blacklist than my syntax above?
3b) What's the best or most consistent way of storing a set of
strings? My ideas so far are: make a TREE_LIST of IDENTIFIER_NODEs
storing the strings, use a VEC (not sure how yet), or manually
alloc/dealloc my own list.
4) I'm placing the bulk of my code at the end of [cp/except.c] but I
feel it's probably better as it's own file, [cp/res.c].
Should I use my own file, or just stick with appending [cp/except.c]?
How do I go about adding a .c file to the make? [configure] looks
hideous, please say I don't have to hack inside there.
5) I'm adding this because a) I want to use it myself and b) because
many people requested it. But it's taking me a lot of time. I'm also
about to finish up my current job. I have to ask - is there any
sponsorship available, because if there were I could work on this
full-time instead of the occasional few hours a month, and perhaps fix
the bug in #2.
