> Whether FP state is saved and restored for signal has been a
> contentious issue.  In 99.9999% of programs, floating point state
> wouldn't be modified in a signal handler so why save and restore it?

The same could be said of a lot of things that are saved and restored
in a lot of contexts.  (I also think you have way too many nines
there.)

> Indeed, given the existance of sig_atomic_t as an int type implies
> that FP usage in a signal handler is unpredictable.

No - only that FP arithmetic on values shared with non-signal use is
unpredicable.  But something like

	printf("%.2f%% done\n",done*100.0/total);

inside a SIGINFO handler is totally reasonable.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B