Sorry, I sent my previous reply too soon.
> 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 tech-talk discussion in this thread:
http://www.aps.anl.gov/epics/tech-talk/2012/msg02251.php
The change was made in asyn R4-21, and is documented in 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.”
> How many things would this change break ?
The problem is that currently an asyn port driver will see different behavior if it receives a string written with a stringout record compared to the same string written with a waveform record. For a stringout record the length passed to the driver does not include the trailing nil, while for a waveform record is does include the trailing nil. This is independent of whether the waveform record is written to with caput -S, or medm, or dbpf at the iocsh.
Since readIt does include the trailing nil, and since the waveform record does include the trailing nil on write, then I suggest that the correct fix is to include the trailing nil on write from the stringout record.
Mark
________________________________________
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
>
- References:
- Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- Re: Inconsistency in devAsynOctet for stringout and waveform records Torsten Bögershausen
- RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- Navigate by Date:
- Prev:
Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
- 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
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- 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
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|