Some bi and bo record issues for discussion
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Confirmed
|
Low
|
Unassigned |
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?
This could be tagged Codeathon if we can agree what the behaviors should be.