caget returns wrong data when used with subArray record

[Martin Konrad]

Asynchronous caget, camonitor and CS-Studio probe work correctly:

$ caget -c LS1_CA01:RFA_D1150:SN_RD
LS1_CA01:RFA_D1150:SN_RD 1000
konrad@work-ftc-r4300-03:~$ camonitor LS1_CA01:RFA_D1150:SN_RD
LS1_CA01:RFA_D1150:SN_RD 2019-02-07 10:34:32.575448 1000
^C

However, synchronous caget prints the whole array rather than just the
element the subArray record extracts:

$ caget LS1_CA01:RFA_D1150:SN_RD
LS1_CA01:RFA_D1150:SN_RD 17 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

See the attached file for details about the record.

[Andrew Johnson (anj)]

This isn't actually a bug, it's a feature of doing a synchronous get and the fact that the subArray's VAL field *could* return up to MALM elements if the NELM field were set to that.

At connection time a CA channel provides the application with the maximum number of elements that could be transported through that channel. The synchronous ca_array_get() API provides no way for the CA library to tell the application code how many elements were actually returned (NORD) by the get operation — the application hands the library a buffer for a specific number of elements, but there is nowhere for the library to tell the application how many were actually retrieved. The library zero-fills the remainder of the buffer. The asynchronous ca_array_get_callback() API tells the application how many elements were returned in the arguments it passes to the callback routine.

Unless you tell it otherwise the caget program has to assume that the channel will return the maximum number of elements, so that's the buffer size it prepares and prints. If you want it to only fetch and print one element, give it -#1 or use -c to have it do an asynchronous get.