Comment 12 for bug 907761

Revision history for this message
Dirk Zimoch (dirk.zimoch) wrote : Re: [Bug 907761] Re: reading only 1st char of link in "long string" ($) syntax fails in read error

Hi Andrew,

I found time to test your patch today. It looks fine for me. Strings,
links and attributes behave the same now. All are terminated with a
single 0 in all cases, resulting in only the 0 bytes when requesting 1 byte.

If I understood the "dynamic arrays" feature correctly, shouldn't the
char array consist only of strlen()+1 bytes?

 > caget -S DZ:CO.RTYP$
DZ:CO.RTYP$ calcout

 > caget DZ:CO.RTYP$
DZ:CO.RTYP$ 40 99 97 108 99 111 117 116 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

 > caget -#2 DZ:CO.RTYP$
DZ:CO.RTYP$ 2 99 0

 > caget -#1 DZ:CO.RTYP$
DZ:CO.RTYP$ 1 0

 > caget -#0 DZ:CO.RTYP$
DZ:CO.RTYP$ 40 99 97 108 99 111 117 116 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

In the last case, I had expected
DZ:CO.RTYP$ 8 99 97 108 99 111 117 116 0

Or do I misunderstand the "dynamic arrays" feature? The
RELEASE_NOTES.html says:

"It permits a CA client to fetch only the currently valid elements of an
array by specifying a COUNT of zero [...]"

I had expected that the valid elements would be strlen()+1 bytes?

Dirk

Andrew Johnson wrote:
> strncpy() is regarded as a major source of bugs and security problems in
> C code when a programmer forgets to force the terminating zero byte; I
> want to avoid repeating that mistake. In all the cases we're talking
> about we know that the data we are looking at is a character string and
> not just an array of bytes, so we can remove a possible source of bugs
> in client code by nil-terminating the result. This isn't "faking"
> anything, it's trying to maintain the invariant that C strings are
> (supposed to be) nil-terminated.
>
> I fully admit that long strings were a string-and-sealing-wax addition
> to Base, but that's no reason not to file off any unnecessary sharp
> edges so our users don't get hurt unnecessarily.
>
> I'm attaching a patch which allows single-element fetches, fixes the
> double subtraction issues, and adds nil-termination to DBF_STRING fields
> being read as long-string char arrays. If you can try it out I would
> appreciate another set of eyes on the result before I commit it and add
> it to the Known Problems page.
>
> Thanks,
>
> - Andrew
>
> ** Patch added: "fix-907761.patch"
> https://bugs.launchpad.net/epics-base/+bug/907761/+attachment/2660256/+files/fix-907761.patch
>
> ** Changed in: epics-base
> Importance: Low => Medium
>