Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 08 Oct 2004 16:54:51 -0500

The behaviour of the aoRecord as reported is obviously highly undesirable,

so I'm looking at fixing that. We already have the IVOA and IVOV fields

that can be used to tell the record what to do when it has an undefined

value, and I intend to make use of this mechanism to control what happens
when a NaN value is discovered.
For those interested, my solution is basically that instead of setting
prec->udf to FALSE, it should be set to isnan(prec->val). The line where
udf actually gets set may have to move around a little in some cases, but
the idea is basically to ensure that anytime VAL is NaN that UDF gets set,
so the record will go into a UDF/INVALID alarm state.
I'll be applying this fix to the other standard record types that have a
VAL field of type DBF_DOUBLE. It doesn't make sense for the array record
types though, and the digital and long types don't need to worry about NaN
values anyway.
As far as the handling of NaNs elsewhere, Eric provided some information
about how the different platforms C libraries cope - on Unix it is already
possible to use "NaN" in your .db files (and probably in .dbd files too).
There will be some more checking and additional work needed for handling
NaNs in the numeric type conversions though. I personally think NaN
should be made as full a citizen as it reasonably can be, so I would
definitely vote against changing the behaviour of CA, following the
principle of least surprise - apparently it works at the moment, so don't
break it!
Eric is working on an epicsStrtod() routine to make string input
conversions work everywhere, but we can't expect to be able to fix
everything until the platform's C libraries cooperate.
- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System