Comment 10 for bug 907761

I agree that the behavior should be the same for links, attributes and strings. When I saw that strings are not 0 terminated when read partially (and worked) I considered that the "correct" behavior and changed links and attributes accordingly.

The actual client with that I run into this problem was the Tcl interface. When it connects to a channel, it first gets a DBR_CTRL_* structure with element count 1 in order to get EGU etc. After that, it uses DBR_STS_* with the actual element count for any further communication. This failed for link fields. Maybe other clients behave similar. In this situation, the client is not really interested in the value byte.

Nevertheless, I find it questionable to "fake" a 0 into the data. If a client requests less bytes than the full string, it should not expect a 0 termination. Compare to strncpy. Also consider extensions to CA that allow the client to read the array piecewise (-> Ralph's server-side-plugins). In this case the client would have to do extra work to get rid of the additional 0 bytes. Of course from a human's point of view, there is a difference between arrays of 8 bit numbers and strings. But for a computer that's the same. And it adds extra difficulty to programs to handle char arrays differently dependent on their interpretation by a human.

I would add 0 bytes only at the end of the full string, but not at partially read strings.