Re: CVS commit: src/regress/lib/libc/siginfo/sigfpe

[christos%astron.com@localhost (Christos Zoulas)]

In article <200902181546.QAA0000176853%zel459.zel.kfa-juelich.de@localhost>,
Matthias Drochner  <M.Drochner%fz-juelich.de@localhost> wrote:
>
>christos%zoulas.com@localhost said:
>> It siglongjmps out of the signal handler which is illegal
>
>sure?
>
>> http://opengroup.org/onlinepubs/007908799/xsh/siglongjmp.html
>
>This only says that _nested_ signal handlers cause
>undefined results.

These are contradictions and defects in the current standard:

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm

which should be fixed. The bottom line currently is:

    
https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler

>> Do we advance to the next instruction so returning from a signal handler
>> can proceed?
>
>This should certainly happen for asynchonous signals.
>For synchronous ones, it doesn't make much sense.

Right.

>There is a changelog entry for except.c which says:
>-as Klaus confirmed, we cannot rely on the SIGFPE handler to return to
> the next instruction, so jongjmp() back
>
>I'd believe that, just because I can't think of any
>useful way to continue after a hard FP error (or
>integer division by zero, or ILLINST ftm).

Yes we cannot rely on returning to the next instruction, it is non portable
behavior. I am suggesting that we define the behavior for all platforms,
making this consistent (advancing the instruction pointer to the next
instruction by default) and provide a way to select the current behavior
on a signal-by-signal basis with SA_NOADVANCE.

christos