Re: [jwe@bevo.che.wisc.edu: Crashing after complex division by zero]

["John W. Eaton" <jwe at bevo dot che dot wisc dot edu>]

On 15-Jul-1999, craig@jcb-sc.com <craig@jcb-sc.com> wrote:

| >John Eaton's Octave example points out why this do-not-abort-on-complex-
| >divide-by-zero can be useful (especially when coupled to "passing the
| >buck up"):  Octave could deliver a meaningful message to the user,
| >instead of dumping core itself; or it could enable a user program to
| >receive the trap [I do not really know if that can be done in Octave's
| >language - perhaps John can point that out].

I would just like to be able to get IEEE NaNs and Infs (if
appropriate, of course) for complex division instead of a call to
abort.

Perhaps the default behavior on generating NaNs and Infs should be
something other than continuing, but I don't think the default should
be to call sig_die inside z_div and c_div.  There are surely other
places in libf2c where division by zero can occur (check pow_di.cc,
for example) yet c_div and z_div are the only two routines that call
sig_die for division by zero.

FWIW, Octave does not currently give the user a way to control what
happens for IEEE floating point exceptions, but eventually I hope it
will.

| Right, presumably, catching whatever signal sig_die produces would
| at least offer some relief.  But at least compiling without `-Os'
| offers a behavior that, I think, most users (or "OEMs", i.e. people
| embedding g77 or g77-compiled code within their products) would prefer.

On systems that have it, sig_die generates SIGIOT, then calls abort.
So I don't think that catching the signal and then continuing will
help much.  (If I read the man page correctly, catching SIGABRT then
returning normally from the signal handler will still result in
program termination.)

Thanks,

jwe