> I think that the question is, “Why does caput -S include the trailing NUL?”.
No, I don't think so. I just did a test of a waveform record with FTVL=CHAR and using medm to write the string "abc" into that record. This is what I get in devAsynOctet::writeIt with a debugging printf added:
devAsynOctet:writeIt message=abc, nbytes=4
writeIt is being called with the NORD field for nbytes.
I then did the same test with "dbpf" from the iocsh:
epics> dbpf SIM1:WFOutHigh "abc"
DBR_CHAR[4]: "abc"
epics> devAsynOctet:writeIt message=abc, nbytes=4
epics> dbpr SIM1:WFOutHigh
ASG: BUSY: 0 DESC: DISA: 0
DISP: 0 DISV: 1 NAME: SIM1:WFOutHigh
NORD: 4 SEVR: NO_ALARM STAT: NO_ALARM TPRO: 0
VAL: (nil)
epics> dbpf SIM1:WFOutHigh "ab"
DBR_CHAR[3]: "ab"
epics> devAsynOctet:writeIt message=ab, nbytes=3
epics> dbpr SIM1:WFOutHigh
ASG: BUSY: 0 DESC: DISA: 0
DISP: 0 DISV: 1 NAME: SIM1:WFOutHigh
NORD: 3 SEVR: NO_ALARM STAT: NO_ALARM TPRO: 0
VAL: (nil)
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
________________________________
From: Eric Norum [[email protected]]
Sent: Saturday, July 23, 2016 5:51 PM
To: Mark Rivers
Cc: Andrew Johnson; [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records
I think that the question is, “Why does caput -S include the trailing NUL?”.
The existing stringout and waveform record behaviour seems right. A CHAR waveform record can’t till if it is being called on to send ‘long’ strings or arbitrary single-byte data so if told to send N bytes it should do so — it certainly should not try to outguess the caller by looking at the final byte and not sending it if it happens to be ‘\0’.
On Jul 22, 2016, at 1:55 PM, Mark Rivers <[email protected]<redir.aspx?REF=0srAm3Q-cq_wxIEQkRtNEy6_oqC6ZtVLZtqIQkwrjT7cL07cTbPTCAFtYWlsdG86cml2ZXJzQGNhcnMudWNoaWNhZ28uZWR1>> 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?
- Replies:
- Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
- References:
- Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
- 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 Eric Norum
- 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
|