EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: [Bug 1908433] [NEW] Some bi and bo record issues for discussion
From: Andrew Johnson via Core-talk <core-talk at aps.anl.gov>
To: core-talk at aps.anl.gov
Date: Wed, 16 Dec 2020 19:03:42 -0000
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  <20202021  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  <20202021  2022  2023  2024 
ANJ, 16 Dec 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·