Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Sat, 23 Jul 2016 23:29:04 +0000

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.

Mark

________________________________
From: Eric Norum [[email protected]]
Sent: Saturday, July 23, 2016 6:21 PM
To: Mark Rivers
Cc: [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records

So the device at the other end of the wire will see ‘\0’ characters?  That doesn’t seem right to me.
I think that the existing behaviour is correct.  stringout records send strings — and no trailing ‘\0’.  waveform records send blocks of arbitrary bytes.

On Jul 23, 2016, at 4:11 PM, Mark Rivers <[email protected]<redir.aspx?REF=vQWMibMa4aKg9zRQSmd-ru4UccacVDJ4hzXfNTBOjuhdxhxnULPTCAFtYWlsdG86cml2ZXJzQGNhcnMudWNoaWNhZ28uZWR1>> wrote:

So writing a string to a waveform record with Channel Access or dbpf also sets NORD to include the nil byte.

So my conclusion is that the stringout behavior in devAsynOctet is incorrect, it is not including the nil byte in the call to writeIt, but it should be.

Mark

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System