Some bi and bo record issues for discussion

[Andrew Johnson]

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?

[Andrew Johnson (anj)]

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