Re: CA get of zero length array

[Michael Davidsaver <mdavidsaver@gmail.com>]

I remembered that there is an issue open for this

https://bugs.launchpad.net/epics-base/+bug/1242919

On 04/17/2018 11:40 AM, Michael Davidsaver wrote:
> On 04/17/2018 06:18 AM, Jörn Dreyer wrote:
>> ~ $caget -d 2 HIBEF:XFEL:image1:ArrayData | more
>> HIBEF:XFEL:image1:ArrayData
>>     Native data type: DBF_FLOAT
>>     Request type:     DBR_FLOAT
>>     Element count:    1000
>>     Value:            2.02038e-39 0 ...
> 
> Don't ask me why, but I was annoyed at seeing (again) this garbage element
> in what should be a zero'd array.  So I traced it back.  The issue is in
> camessage.c in read_reply().  Specifically, that
> 
>> dbr_size_n(X,0) == dbr_size_n(X,1)
> 
> as the underlying dbr_size[] includes the size of meta-data and one value element.
> 
> So dbChannel_get_count() correctly sets item_count to zero.  Then read_reply()
> zeros part, but all, of the buffer.  In this case data_size includes the first
> value element, which isn't set by dbChannel_get_count(), and not isn't zeroed
> here.
> 
>> ca_uint32_t data_size = dbr_size_n(pevext->msg.m_dataType, item_count);
>> ...
>> memset((char *) pPayload + data_size, 0, payload_size - data_size);
> 
> This is only in the !autosize case (get or non-dynamic monitor).
> 
> I'm not sure where to fix this, as there would seem to be several possibilities,
> depending on whether or not dbr_size_n() should change.
>