The Signal.handle API notionally allows Java code to install a Java handler** for a platform signal (with restrictions), returning the original handler (as an opaque long value that may actually be a function pointer in the VM). The application code can then restore the original handler later.

The problem on Posix systems is that we can have two types of signal handling functions:
- one that takes a single int argument (for the signal number)
  -  typedef void (*sa_handler_t)(int);
- one that takes three arguments to provide additional context
  -  typedef void (*sa_sigaction_t)(int, siginfo_t*, void*);
and when a signal handler is installed you have to tell the OS which kind of handler it is, and store it in a particular place in the `struct sigaction`. The existing API however only has the address of the handler with no knowledge as to which kind of handler it is - and it incorrectly always assumes it is the three argument kind (which can easily cause a crash as the unexpected extra arguments can overwrite other entries on the stack).

We need to change the API such that we know what type of handler is to be installed - suggestion in comments.

** It doesn't really install a Java signal handler function, but a native VM function that wakes up a dedicated Java signal handling thread, which in turn executes the registered Java "handler" for that signal.

Another problem with the POSIX version of JVM_RegisterSignal is that jdk.internal.misc.Signal uses the values 0 and 1 as special markers indicating SIG_DFL and SIG_IGN.  It may pass those values to JVM_RegisterSignal, which does no interpretation but just passes them along as if those marker values were indeed the corresponding values.  It happens they match up in the Linux headers, but there's nothing in the POSIX documentation to require that.