Re: Inconsistency in devAsynOctet for stringout and waveform records

[Eric Norum <wenorum@lbl.gov>]

But it seems to me that what you are requesting is what creates the need for drviers to require two paths and to somehow intuit which one to take.

I think that we’re in agreement that sending null characters to a device is a bad idea, right?  If so, then if the stringout record included the trailing null in the request count how could a driver know that in this case it should strip the trailing null when in the case of being called from a waveform record it should send the full request?

I think the existing behaviour is right.  Drivers send the actual request count (which in the stringout case does not include the terminator).  If a waveform record is being used to handle long strings writers should not include the trailing terminator in the request count.  This is where I think that caput -S is now doing things incorrectly.

On Jul 23, 2016, at 4:29 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

The problem is that then all asyn port drivers that are expecting to receive strings need to handle two different cases, one where the length being passed includes the nil, and one where it does not.  When the user changes from a stringout to a waveform record because their string just exceeded 40 characters, the driver receives something fundamentally different.

Is this what we want?

I am not proposing that we change the ability of the waveform record to handle arbitrary data, because I am not changing the behavior for the waveform record.  I am proposing changing the behavior of the stringout record to match the waveform record.