newLISP Fan Club

Quote— Macro: int SIGFPE



    The SIGFPE signal reports a fatal arithmetic error. Although the name is derived from "floating-point exception", this signal actually covers all arithmetic errors, including division by zero and overflow. If a program stores integer data in a location which is then used in a floating-point operation, this often causes an "invalid operation" exception, because the processor cannot recognize the data as a floating-point number. Actual floating-point exceptions are a complicated subject because there are many types of exceptions with subtly different meanings, and the SIGFPE signal doesn't distinguish between them. The IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985 and ANSI/IEEE Std 854-1987) defines various floating-point exceptions and requires conforming computer systems to report their occurrences. However, this standard does not specify how the exceptions are reported, or what kinds of handling and control the operating system can offer to the programmer.



BSD systems provide the SIGFPE handler with an extra argument that distinguishes various causes of the exception. In order to access this argument, you must define the handler to accept two arguments, which means you must cast it to a one-argument function type in order to establish the handler. The GNU library does provide this extra argument, but the value is meaningful only on operating systems that provide the information (BSD systems and GNU systems).



FPE_INTOVF_TRAP

    Integer overflow (impossible in a C program unless you enable overflow trapping in a hardware-specific fashion).

FPE_INTDIV_TRAP

    Integer division by zero.

FPE_SUBRNG_TRAP

    Subscript-range (something that C programs never check for).

FPE_FLTOVF_TRAP

    Floating overflow trap.

FPE_FLTDIV_TRAP

    Floating/decimal division by zero.

FPE_FLTUND_TRAP

    Floating underflow trap. (Trapping on floating underflow is not normally enabled.)

FPE_DECOVF_TRAP

    Decimal overflow trap. (Only a few machines have decimal arithmetic and C never uses it.)

Quote

Code Select Expand

#ifdef OS2
     /* SIGFPE must be forced for a NaN Inf */
   /* the longjmp returns 1 to setjmp when set */
   case SIGFPE:
      longjmp(errorJump,errorReg);
      break;
#endif


Quote from: "Lutz"


The following



- longjmp() doesn't return anything is void longjmp()

- setjmp() returns whatever the second arg of longjmp() was

- errorReg is always set to the return value of setjmp()

Quote

Code Select Expand


if((errorReg = setjmp(errorJump)) != 0)
    {
    if(errorReg && (errorEvent != nilSymbol) )
        executeSymbol(errorEvent, NULL, NULL);
    else exit(-1);
    goto AFTER_ERROR_ENTRY;
    }

errorReg = setjmp(errorJump); <=== will suppress all error messages
setupAllSignals();


Quote from: "Lutz"Nope! From the man page of longjmp():



"Returns 0 after saving the stack environment. If setjmp() returns as a result of a longjmp() call, it returns the value argument of longjmp(), or if the value argument of longjmp() is 0, setjmp() returns 1."



That means setjmp() does return the second arg of longjmp(), except when that arg was 0, then setjmp() returns 1.



For that reason I wanted you to try longjmp(errorJmp, 0) in the error handler earlier.



Also, when you do this:

Quote

Code Select Expand


if((errorReg = setjmp(errorJump)) != 0)
    {
    if(errorReg && (errorEvent != nilSymbol) )
        executeSymbol(errorEvent, NULL, NULL);
    else exit(-1);
    goto AFTER_ERROR_ENTRY;
    }

errorReg = setjmp(errorJump); <=== will suppress all error messages
setupAllSignals();


You effectively suppress all error messages, because the jump buffer is now set to that point with no error treatment when an error occured. It will then just drop into the command line without error messages.



That line has to go, we have to make OS/2 FP work without it.

QuoteWhat I could do is extract the SIGFPE from the generic handler in newlisp?