RE: Inconsistency in devAsynOctet for stringout and waveform records

[Mark Rivers <rivers@cars.uchicago.edu>]

> This is where I think that caput -S is now doing things incorrectly.

But it is not just caput -S.  It is medm, and dbpf in the IOC shell, etc.  I think that ship has sailed: strings in waveform records include the nil in NORD.  In fact that is what Andrew recommended in this thread for the inverse problem, i.e. reads from a driver:

http://www.aps.anl.gov/epics/tech-talk/2012/msg02251.php<http://www.aps.anl.gov/epics/tech-talk/2012/msg02251.php>

asynPortDriver is now doing it that way on read operations.

Mark



________________________________
From: Eric Norum [wenorum@lbl.gov]
Sent: Saturday, July 23, 2016 6:43 PM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records

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<redir.aspx?REF=fis2kRoQaO-WzVqEI0E1NtRHOLgUx0SkeOsSi2yRXWggtf_BWrPTCAFtYWlsdG86cml2ZXJzQGNhcnMudWNoaWNhZ28uZWR1>> 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.