EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Inconsistency in devAsynOctet for stringout and waveform records
From: Mark Rivers <[email protected]>
To: Torsten Bögershausen <[email protected]>, "'Eric Norum'" <[email protected]>, Andrew Johnson <[email protected]>
Cc: "[email protected] list" <[email protected]>
Date: Sat, 23 Jul 2016 23:14:33 +0000
> For readIt(), the driver returns the length of the payload,

No, that is not true.  This is from asynPortDriver::readOctet

    *nActual = strlen(value)+1;

So it returns the length including the nil byte. 

This change was made after much tech-talk discussion in asyn R4-21:


________________________________________
From: Torsten Bögershausen [[email protected]]
Sent: Saturday, July 23, 2016 5:34 PM
To: Mark Rivers; 'Eric Norum'; Andrew Johnson
Cc: [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records

How should the interface to the driver be ?

For readIt(), the driver returns the length of the payload,

and asyn adds 1 for the terminating NUL before going out to the rest of
EPICS.

(Please correct me, if this is wrong)

For writeIt(), I would prefer to use the same principle,

and use the length of the payload, 3 in our case.

This would be in line with what the unix read() and write() functions do,

and, what I understand, the asyn-record does.

And, would need changes for the waveform record.

How many things would this change break ?


On 07/22/2016 10:55 PM, Mark Rivers wrote:
>
> 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
>



Replies:
RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
References:
Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
Re: Inconsistency in devAsynOctet for stringout and waveform records Torsten Bögershausen

Navigate by Date:
Prev: RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
Next: Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Inconsistency in devAsynOctet for stringout and waveform records Torsten Bögershausen
Next: RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 23 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·