Print

---

At the risk of getting flamed again for talking about obsolete
software....

Is the fact that floating point exception handling is not working within
primdat on Linux seen as a bug or a feature?

ie has the software now migrated to dealing with Inf and NaN or should
PRM be "fixed"? I see that kaplibs has routiens for testing Inf and NaN
but I'm not sure if they are used everywhere. The fact that NUM_ERROR is
present in code suggests that there is a demand for it.

Anyway, my point is that

 1. C99 supports fine grained testing of floating point exceptions
    (Without a SIGFPE being triggered)

 2. NUM_ERROR now has a function interface rather than a raw common block
    interface

The above two points indicate to me that it should be fairly simple to
reinstate floating point exception handling again simply by

 1. Throwing away NUM_CMN completely

 2. Make NUM_CLEARERR call  feclearexcept (FE_ALL_EXCEPT);

 3. Make NUM_WASOK    do something like:

    raised = fetestexcept (FE_ALL_EXCEPT );

 4. Make NUM_GETERR  do something like

    raised = fetestexcept (FE_ALL_EXCEPT );

    if (raised & FE_DIVBYZERO) return PRM__INTDZ;

This may well cause surprise for people that are registering their own
numeric handler routines (Which will no longer be called).

Note that in the new scheme, you will still get Inf and NaN
(no SIGFPE), you'll just be able to spot the exception without checking
whether you got Inf or NaN excplicitly (using the kaplibs routines).
But in that case VEC_ is lying since it will never insert bad pixels
and so an additional loop will always be required to fix up Nan/Inf to be
bad values.

Obviously people may also object that the PRM routines will now all have
to use a function call rather than an inline common block access. [I
imagine we need to benchmark ccdpack after making the change]

Currently, I can only trigger the SIGFPE if NUM_WASOK does it itself
on the basis of the C99 exception test.

--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj