Public bug reported:
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?
** Affects: epics-base
Importance: Low
Status: Confirmed
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1908433
Title:
Some bi and bo record issues for discussion
Status in EPICS Base:
Confirmed
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?
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1908433/+subscriptions
- Replies:
- [Bug 1908433] Re: Some bi and bo record issues for discussion Andrew Johnson via Core-talk
- Navigate by Date:
- Prev:
[Bug 1881563] Re: Empty arrays have undefined behavior Andrew Johnson via Core-talk
- Next:
[Bug 1908433] Re: Some bi and bo record issues for discussion Andrew Johnson via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
[Bug 1908305] Re: Default DTYP can be changed by DBD file order Andrew Johnson via Core-talk
- Next:
[Bug 1908433] Re: Some bi and bo record issues for discussion Andrew Johnson via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|