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  2020  <20212022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: [Bug 1938459] Re: int64in only checks lower 32 bits for change
From: mdavidsaver via Core-talk <core-talk at aps.anl.gov>
To: core-talk at aps.anl.gov
Date: Thu, 29 Jul 2021 16:13:41 -0000
> One fix should be to replace epicsUInt32 with epicsUInt64 in DELTA and
where it's used.

Can you try replacing all three mentions of 'epicsUInt32' with
'epicsUInt64'?

It looks like int64outRecord.c is correct.

-- 
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/1938459

Title:
  int64in only checks lower 32 bits for change

Status in EPICS Base:
  New

Bug description:
  Create an int64in record and write these values
  (example uses bash to convert hex into decimal since caput cannot directly handle hex?):

  caput sixtyfour $(( 16#FF ))
  Old : sixtyfour                      0
  New : sixtyfour                      255

  caput sixtyfour $(( 16#87654321 ))
  Old : sixtyfour                      255
  New : sixtyfour                      2.27156e+09

  caput sixtyfour $(( 16#32187654321 ))
  Old : sixtyfour                      2.27156e+09
  New : sixtyfour                      3.44254e+12

  A camonitor will show 255, then 2.27156e+09, but not 3.44254e+12. A
  caget or a newly started camonitor will see the latest value.

  Reason is this section in int64inRecord.c:

  /* DELTA calculates the absolute difference between its arguments
   * expressed as an unsigned 32-bit integer */
  #define DELTA(last, val) \
      ((epicsUInt32) ((last) > (val) ? (last) - (val) : (val) - (last)))

  It only checks for changes in the lower 32 bits of the value.
  Maybe the motivation was to always perform an _unsigned_ comparison, but "UInt32" was copy/pasted instead of "UInt64"?

  One fix should be to replace epicsUInt32 with epicsUInt64 in DELTA and
  where it's used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1938459/+subscriptions


References:
[Bug 1938459] [NEW] int64in only checks lower 32 bits for change kasemir via Core-talk

Navigate by Date:
Prev: [Bug 1938459] [NEW] int64in only checks lower 32 bits for change kasemir via Core-talk
Next: Jenkins build is back to normal : EPICS-3.14 #1109 Jenkins EPICS PSI via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: [Bug 1938459] [NEW] int64in only checks lower 32 bits for change kasemir via Core-talk
Next: [Bug 1938459] Re: int64in only checks lower 32 bits for change kasemir via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 29 Jul 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·