Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Mon, 12 Nov 2012 13:53:18 -0800

On Nov 12, 2012, at 1:42 PM, Mark Rivers <[email protected]> wrote:

>> But if there's no space in the waveform for the terminating '\0' I don't see how making changes
> 
>> to setStringParam is going to help either.
> 
> 
> 
> There IS space in the waveform record, that's not the problem.
> 
> 
> 
> The problem is that with the changes made recently in EPICS when a client requests a monitor callback with a size of 0.  In this case the array returned in the callback now has exactly NORD elements.  The problem is that asynPortDriver is currently setting the length of the array to strlen(array).  So NORD is set to strlen(array).  Clients thus receive arrays without a Nil terminator.
> 
> 

I see.

> Your change to devAsynOctet does not fix this problem, because it does not increase NORD when it adds the Nil.  I argue that it cannot increase NORD because that will break support for binary data in devAsynOctet.
> 
> 
> 
> I think the correct solution is to change asynPortDriver (and perhaps other drivers) so that when they return strings (but not binary arrays) to the waveform record, either with pasynOctet->read() or asynOctet callbacks they set NORD to strlen(array)+1, and add the Nil terminator.
> 
> 

Maybe, but I feel like this is pandering to broken clients.

> 
> This does have a slight potential to break existing clients, because the meaning of NORD has now changed.

Right.
Is this effort and possibility of breakage of (proper?) clients worth the gain in cleaning up the behaviour of (broken?) clients?
I mean, we don't guarantee that the contents of a stringin record are nil terminated do we?  (this is a real question -- I've always been under the assumption that a client couldn't count in this, but I really don't know for sure).

-- 
Eric Norum
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System