Re: Re: Re: Detecting finally blocks?

On 2009-12-17, at 8:35 PM, Scott Vachalek wrote:

> The finally block itself may appear multiple times due to inlining, but I think a catch block with null type should only be the catch-all block which gets created implicitly whenever a finally block is present.  Any catch blocks which are declared by the programmer should have the type declared in the source.
> 
> This is just the habit of Java compilers though; I don't think it's required by the JVM spec, so it's not something you can rely upon entirely.  But I've never seen a null catch generated by javac for any other reason.  The contents of the handler (save exception, repeat finally code, throw saved exception) are also very predictable.

Beware, slightly, of the output of code obfuscators.  There was (is, I think) an "industry standard benchmark" whose obfuscated classfiles contained non-nested overlapping PC ranges for try blocks.

There's also a crypto library out there that has unbalanced monitorenter/monitorexit, with a branch out of the balanced register that is guarded by a reference to a never-true private static.

I only know about these things because they gave a compiler I was working on digestive problems, but as a practical matter, these are not substantial impediments to anyone who cares to get to the code.  Obfuscation buys you maybe one week's protection from reverse engineering, plus a bunch of pissed-off compiler (and tool) writers.

David

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws