Undefined ao record wrongly resets UDF when processed

I'm not sure I agree. Processing w/ VAL=0 (the default) should clear UDF. I know I created DBs which depend on this.

Hm.

So why is only the ao records acting this way, and all other record types stay UDF/INVALID after processing?

I would say the general concept is that a val is being defined by writing to it.

For input records this is usually done though processing, that's obvious.

IMHO, for output records the value should be defined:
- if the init_record() routine has code for reading back the value from hardware and successfully writes val
- if the database file sets VAL/DOL to a default value
- if autoSaveRestore sets val to a saved value
- if the record is in closed_loop and the val gets fetched using DOL
- if the record is in simulation mode and the vale gets fetched using SIOL.

But for the gives case (no value from database, not closed_loop, no simulation mode) I would argue that processing itself does not define val.

In any case: I think the behavior should be consistent across record types.

If you want an ao record to stay invalid after processing when nothing explicitly sets its VAL field you can set that VAL field to NaN in the DB file. We could change the default value of VAL to be NaN but I'm not sure if that would be a good idea at this point.

Looking briefly at the code I suspect this is happening because even if nothing writes a new VAL the record still has to call convert() to handle an OVAL value changing due to OROC.

Maybe this is a "feature" of the ao record that just needs to be documented (like the HIGH field of the bo record which is similarly unique), with "set VAL to NaN" given as a workaround if you prefer the UDF behavior.

So in aoRecord.c you're proposing to change all:

> prec->udf = isnan(prec->val);

to

> prec->udf |= isnan(prec->val);

?

Re Michael: not in all places, only when val was not written to by anything.

In general: I could live with any reasonable behavior, but I would really like the behavior to be consistent across record types.

Re Andrew: I agree that in principle, NaN would be a better default for analog record types. The problem is again consistency: there is no NaN equivalent for the binary and enum record types.

So is the real issue that inside ao::process() the statement

    prec->udf = isnan(prec->val);

is in the wrong place? The OIF processing complicates the aoRecord sufficiently that it isn't immediately obvious what the right place for it would be — ao::fetch_value() and ao::convert() both appear to be possible candidates. ao::fetch_value() knows whether the dbGetLink() succeeded and looking back that's where prec->udf was cleared in 3.13 days (before we did the isnan() thing), but the code that actually writes to prec->val is inside ao::convert() which is only called when ao:fetch_value() returns OK.

What would your proposed change be?