Re: increase in object code size

[Joe Buck <jbuck at synopsys dot com>]

> > The first optimization which comes to mind: an exception table entry
> > which does not apply to an instruction which can throw an exception
> > should be eliminated.  In GNU C and C++ (and, I think, GNU Ada) only
> > function calls throw exceptions.  That means there needs to be at most
> > one table entry per function call.
> 
> No, because you will want to support throwing exceptions from 
> signal handlers.  This is most useful from synchronous signals
> such as SEGV and FPE, but I could also see uses for ALRM.

Forget it.  You can't support throwing asynchronous exceptions from signal
handlers.  If you attempt to, you can't write reliable code.  (You may
be able to support SEGV and FPE if you can always clean up the stack,
but I wouldn't advise it).

Consider this:

	char* p = 0;
	try {
		p = malloc(100);
	}
	catch (...) {
		if (p != 0)
			free(p);
	}

Question: is this correct if the ALRM handler throws an exception?  Can we
guarantee no memory leaks or frees of unallocated memory?

Answer: no; not even if we put locks inside malloc, since there isn't
a way to put a lock between the return of malloc and the assign of p.
You'll never debug failures coming from this.