Re: GCJ/minGW produced executables and linux/wine

["Ranjit Mathew" <rmathew4lists at hotmail dot com>]

>  > Well honestly, I don't know and I'm surprised that it works
>  > on Linux (so signal delivery must be the "last mile" in that
>  > the OS doesn't really care if the handler returns or not).
>
> The ANS C standard says that signal handlers may return by doing a
> longjmp.  But that's what I meant whan I said this is not a signal
> handler and may have other restrictions.  And it seems like it does
> indeed have some restrictions.

I found a GCJ document relevant to this discussion at:

    http://gcc.gnu.org/java/port-signals.html

(I had seen it before, but hadn't understood its signficance till now. ;-))


>  > I can imagine that there would be problems on Win32 because
>  > this handler is supposed to return a value to the OS telling
>  > it whether to execute the default handler (abort program)
>  > or whether the exception has been handled successfully.

My conjecture seems correct as this simple program hangs on Win32
after printing "Strike 1!", instead of printing "Strike 2!" as well:
------------------------------- 8< --------------------------------
public class Snafu {
  public static void main( String[] args) {
    Object p = null;
    try {
      System.out.println( p.toString( ));
    } catch( NullPointerException e) {
      System.err.println( "Strike 1!");
    }

    try {
      System.out.println( p.toString( ));
    } catch( NullPointerException e) {
      System.err.println( "Strike 2!");
    }
  }
}
------------------------------- 8< --------------------------------

I guess instead of blindly throwing NullPointerException from within
win32_exception_handler( ) in win32.cc, we will have to modify
the return address a la MAKE_THROW_FRAME in posix.cc, and return
EXCEPTION_CONTINUE_EXECUTION as explicitly allowed by Windows:

http://msdn.microsoft.com/library/en-us/debug/base/setunhandledexceptionfilter.asp

Ranjit.