Some bi and bo record issues for discussion

Bug #1908433 reported by Andrew Johnson
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

1. Should bo.VAL and bi.VAL always be forced to 0 or 1 only?

The code in bo::process() that reads DOL can result in VAL being set to something other than 0 or 1. Almost everywhere else the code that sets VAL prevents that; the only other place I can see is that IVOV isn't limited to 0/1 and gets copied to VAL if IVOA triggers it; or a put from elsewhere could also set it to a non-boolean value. This can also result in RVAL being set to something other than 0, 1 or MASK.

The bi::readValue() routine copies SVAL to VAL in simulation mode without checking it for 0/1, and any bi device support could also set VAL to some other value and return 2.

Both get_enum_str() routines handle the invalid case by returning "Illegal_Value".

2. Both get_enum_strs() routines currently return 1 string if ZNAM is set but not ONAM, or 2 strings in all other circumstances (neither ZNAM nor ONAM set; ONAM set but not ZNAM; or neither ZNAM nor ONAM set). There is a comment in that bo code saying that returning 0 strings breaks CA clients, but the mbbi and mbbo records both do that if no strings are defined, so that comment might be out of date now. Should bi/bo behave like an mbbi/mbbo with NOBT=1?

Revision history for this message
Andrew Johnson (anj) wrote :

This could be tagged Codeathon if we can agree what the behaviors should be.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.