Experimental Physics and
Industrial Control System

Hi Eric and Andrew (and others),

 

I have just found an inconsistency in the devAsynOctet.c for handling string output for stringout records versus waveform records.

 

I have a stringout record which I process as follows:

caput SIM1:SOHigh "abc"

 

This is the output of devAsynOctet.c with some debugging statements added:

devAsynOctet::callbackSoWrite, calling writeIt with message="abc", nbytes=3

 

This is what happens when I write the same string with a waveform record:

caput -S SIM1:WFOutHigh "abc"

 

devAsynOctet::callbackWfWrite, calling writeIt with message="abc", nbytes=4

 

So in the case of the stringout record the length being passed to the driver is strlen() of the string, while for the waveform record it is the NORD field of the waveform record.  NORD includes the terminating 0 byte.

 

This difference in behavior is causing me problems when extending the Modbus driver to handle strings.

 

Which do you feel is the “correct” behavior?  Should the driver be called with nbytes including the trailing 0 or not? 

 

You may recall that in asyn R4-21 we made the following change (from the release notes):

“Changed the code so that the length of string parameters returned in readOctet and octetCallback is now strlen(string)+1, rather than strlen(string). The length thus now includes the terminating nil. This fixes problems with clients that request long strings or subscribe to monitors with a length of 0, but don't check for a nil terminator.”

 

So we do include the terminating nil in the length for readOctet.  For consistency it seems like the nil should be included in the length passed to the driver from writeOctet.  This means the stringout record support is the one that needs to be changed.

 

Mark