[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]



I maintain the Debian yorick package, which needs SIGFPE signals to be
delivered in order to function properly.

Very recently the __setfpucw function which accomplished this task has
been switched from an extern symbol in libc to a local symbol
(presumably to be called before main).  That change represents a
backward compatibility problem -- the new libc will no longer run
Debian 2.0 codes (like yorick) which called __setfpucw.  I'm tempted
to report that as a glibc bug, but I thought I'd ask you first.

This function and the associated fpu_control.h header file have a
history of moving around and being a portability headache.  Apparently
the current recommendation is to use the (undocumented?) _FPU_SETCW
macro defined in fpu_control.h.  Is that true?  Is it likely to remain
there?  What am I supposed to do for the alpha platform, where
fpu_control.h does not define _FPU_SETCW -- do I need to use the
Digital-UNIX-like ieee_set_fp_control function (defined in asm/fpu.h)
on that one Linux platform, and _FPU_SETCW on all the others?

Would you be willing to make a "turn on sane SIGFPE delivery" macro
that could go in some standard place (like fpu_control.h) on every
platform?  Without such a standard, you may as well withdraw the
SIGFPE functionality from the signal and sigvec family of functions,
since that signal is never delivered by default, and there is no
standard way to request delivery...  I admit the situation is
complicated because nobody wants *all* the possible interrupts (such
as underflow or loss of precision) delivered, but a great many
numerical programs simply can't work correctly and efficiently without
SIGFPE delivery.

By the way, you should remove the __setfpucw man page from your doc
package; it's terribly outdated.

Thanks very much for any advice you can give me about how to maintain
a Debian package that needs SIGFPE delivered across all the supported

Dave Munro

Reply to: