From: "Douglas A. Gwyn" <DAGwyn@null.net>
Newsgroups: comp.std.c
Subject: Re: cpow
Date: Tue, 21 Jul 1998 09:02:29 GMT

Nick Maclaren wrote:
> >in which case return from SIGFPE is explicitly undefined behavior.
> That particular insanity was PRECISELY because Intel cocked it up!

No, it's a more general problem -- if you *return* to the point
of interruption, what is going to prevent the same event that
caused the exception in the first place?  C doesn't provide any
method of cleaning things up before such a return; it doesn't
even provide any (portable) method of discovering more precisely
what the detailed cause of the exception was.

> You have exactly the same problem with asynchronous signals (such as
> SIGINT, SIGTIME etc.) under Unix.  If they are trapped while library
> code is executing a system call, then that call will usually fail, ...

This occurs only for "slow I/O", e.g. input from a terminal,
and the idea was to not lock up the process waiting for I/O
that might not occur for a *long* time if ever.  Indeed, the
typical case is a user typing the INTR character while the
process is waiting for keyboard input.