Comment 3 for bug 1881563

Revision history for this message
Andrew Johnson (anj) wrote :

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.