Exception Specifications & code quality

[Nathan Sidwell]

Last month there was a thread about checking exception specifications
and warning on any leaked exceptions
( http://www.cygnus.com/ml/egcs/1998-Aug/0252.html ) I've noticed
something about the exception unwind code, which is related

Consider the following piece of code,
	void fn_char() throw(char);
	void fn_char1() throw(char)
	  {fn_char();}

fn_char1 produces exception unwinding code which checks if it's going to
throw an object outside the set of its exception specification. (I've
attached the sparc assembler produced at -O2). This is, of course, not
possible.

The code I'm talking about is between LL3 and LL16. I must say, I'm a
little surprised about the exception unwind blocks LLEHB14, LLEHB7 and
LLEHB10 around this, surely the routines __cp_eh_info, __tfc,
__check_eh_spec cannot throw?

This isn't an execution speed problem, because this is the exception
path, but it is a code size issue.

As with checking exception specifications, you need to scan over the
function body creating the union of all uncaught thrown types (from
throw statements and function calls). Then if this is a subset of the
function's throw specification no runtime check is required. Solving
this problem gives the oportunity for the warning, if you really want
it. Like the 'this var may be used uninitialized' warning, you'd only
get it when optimizing (and you asked for it!).

Just thought I'd share this with you.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk