Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <core-talk at aps.anl.gov> · Thu, 04 Jun 2020 01:24:26 -0000

The array length part of #1 is a fundamental limitation of using caget
(which calls ca_array_get()) instead of 'caget -c' =>
ca_array_get_callback() since only the latter API provides a way to
return the actual element count to the application code. Did I read in
email that someone has a fix for #1242919? Applying that would ensure
the first element does get returned as zero to a ca_get() caller, but
fixing the length part would require changing the ca_array_get() API,
the result of which would probably look just like
ca_array_get_callback(). IIRC 'caget -c' doesn't show the random first
element anyway, so I see #1 as just a duplicate of
https://bugs.launchpad.net/epics-base/+bug/1242919

#2 is correct behavior. Using the -F option to camonitor (and 'caget
-c') might make that more obvious (IIRC there should be no field
separators at all for an empty array).

#3 The scalar device supports call dbGetLink() with nRequest=NULL (which
is short-hand for 1 element). For a DB link pointing to an array with
zero elements that should end up calling dbGet() and that will use of
the dbFastGetConvertRoutine[][] routines to copy and convert the first
element from the source array (even when that source nominally has zero
elements). Thus I'm not sure that your description of this bug is quite
right, you need to initialize the source array to have a non-zero first
element, then set its array length to 0 without overwriting the data
buffer. Might be easiest to do that using an aSub record.

#4 devAaiSoft.c calls dbGetLink() to fetch the data, but only updates
NORD if nRequest>0 on return. devWfSoft.c does the same thing in a
slightly different way. Both also have nelm>0 checks in their
init_record() routines so constant input array initialization to an
empty array won't ever set NORD to zero (which it defaults to anyway) or
clear UDF (which is the detectable bug in this code). We should also
test the subarray record, its soft-device support also has similar code,
and the aSub record also only updates the array length of its input
fields if nRequest>0.

#5 We don't know yet whether this is just an issue with the caput
program, or whether the underlying CA client library is unable to do
zero-length puts. Can you try using an aao or aSub record with a CA
output link to write a zero-length to a non-empty array record to see
whether the destination gets its length set to 0 please.

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

Title:
  Empty arrays have undefined behavior

Status in EPICS Base:
  New

Bug description:
  The behavior of arrays with 0 elements is inconsistent and seemingly
  undefined. I made the fllowing observations:

  1. Reading empty arrays with caget shows NELM values, all 0 except for
  the first which sometimes contains strange not-quite-random numbers
  (see bug report 1242919). I have observed values 0, 2.122e-314,
  2.50321e-308, 22, 18, 2.02038e-39, 1441792, 1179648, 3.05948e-308,
  also depending on the -d option (DBR type) of caget.

  2. Reading empty arrays with camonitor shows no values.

  3. A scalar input record reading INP or scalar output record reading
  DOL (with OMSL closed_loop) from an empty array (aai, aao or waveform)
  reliably reads the value 0 (tested with ai, bi, mbbi, mbbiDirect,
  longin, stringin, ao, bo, mbbo, mboDirect, longout, stringout). This
  is true for DB links as well as for CA, CP and CPP links.

  4. An array record (aai, waveform) reading from an empty array does
  not change its current value. It does not change NORD, it does not
  clear the arrays elements, it does not show an alarm.

  5. Writing 0 elements to an array with caput -a fails whith "Invalid
  element count requested".

  My opinion on this behavior is as follows:

  1. Reading arrays with caget should return NORD elements, not NELM
  elements. But if we put this side, the additional elements should all
  be set to 0. For empty arrays, this includes the the first one (index
  0).

  2. This is correct behavior.

  3. This is consistent but questionable. Converting an empy array to a
  scalar should fail as there is no value to convert. But that might
  break existing dbs. In that case this behavior should be documented.
  (Or is it?)

  4. This behavior is buggy. The receiving record should update its NORD
  to 0.

  5. It should be possible to write an empty array.

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System