Hi Eric,
O.K., but given the proposal to change stringout support to include the trailing null I don’t see how drivers are going to avoid
sending null terminators when handling a request from a stringout record.
As I said in my response to Torsten I think it is very rare that devAsynOctet.c is being used to send strings directly to the drvAsynIPPort or drvAsynSerialPort drivers, for example. Almost everyone uses StreamDevice or other device support for stringout or waveform out records that send strings to hardware. devAsynOctet is almost always used to send string to "intermediate" drivers like motor, modbus, areaDetector, etc. which may in turn do I/O to the drvAsynIPPort or drvAsynSerial port drivers.
In the existing version of asyn if a waveform record is being used in the application you envision then a waveform record WOULD send the null terminator, while a stringout record would not. But this difference is exactly what I want to avoid. Since I am not aware of anyone reporting problems with the waveform record, I assume that it is not really a problem. Making the stringout record be consistent with the waveform record carries a slight risk of breaking existing applications, but I think the benefit to simplifying writing asyn port drivers is worth the risk.
Mark
________________________________
From: Eric Norum [[email protected]]
Sent: Saturday, July 23, 2016 7:48 PM
To: Mark Rivers
Cc: [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records
O.K., but given the proposal to change stringout support to include the trailing null I don’t see how drivers are going to avoid sending null terminators when handling a request from a stringout record. Well I suppose drivers could always sent one byte fewer than every request but that seems even worse.
On Jul 23, 2016, at 5:42 PM, Mark Rivers <[email protected]<redir.aspx?REF=sgL1HUsk2c1t9fit3HTDz-OqkdsSufvar8claCYJuz9KL5dPybPTCAFtYWlsdG86cml2ZXJzQGNhcnMudWNoaWNhZ28uZWR1>> wrote:
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><redir.aspx?REF=VH6T2IHAhD8fedY_s4uh5FCaBHTMZJ6rY0CJLep-Z1hKL5dPybPTCAFodHRwOi8vd3d3LmFwcy5hbmwuZ292L2VwaWNzL3RlY2gtdGFsay8yMDEyL21zZzAyMjUxLnBocCUzQ2h0dHA6Ly93d3cuYXBzLmFubC5nb3YvZXBpY3MvdGVjaC10YWxrLzIwMTIvbXNnMDIyNTEucGhwJTNF>
asynPortDriver is now doing it that way on read operations.
Mark