This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [Hakon.Bugge@scali.com] libc/1739: signal+siglongjmp destroys FP control word on x86


> From: Andreas Jaeger <aj@suse.de>
> Date: 15 May 2000 16:18:33 +0200

> 
>        The environment of a call to the setjmp macro consists of
>        information sufficient for a call to the longjmp function to
>        return execution to the correct block and invocation of that
>        block, were it called recursively.  It does not include the
>        state of the floating-point status flags, of open files, or of
>        any other component of the abstract machine.
> 
> Since siglongjmp is an extension of setjmp/longjmp only with respect
> to signal handling, it seems that I can close the bug report with the
> comment "You're right - but we're following the ISO C standard which
> explictly forbids this".
> 
> What do you think?

You are right.  If the user is changing the FPU flags (either
explicitly with fenv.h or implicitly by executing a FPU operation),
the user should save and restore them in the signal handler.  If the
compiler is doing it, the compiler is responsible for knowing about
setjmp().

It's useful that signal handlers (eg. SIGFPE) can set flags in the
FP environment, like 'overflow', and call siglongjmp().

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]