Experimental Physics and
Industrial Control System

2 Comments here:
- The readIt() implementation add a trailing NUL,
  if there is space in the buffer:
  asyn/drvAsynSerial/drvAsynIPPort.c, line 778:
    /* If there is room add a null byte */
    if (thisRead < (int) maxchars)
        data[thisRead] = 0;
    else
        reason |= ASYN_EOM_CNT;
    if (gotEom) *gotEom = reason;

However, it seems as if the ASYN_EOM_CNT "get lost"
and the  asynPortDriver does not check for ASYN_EOM_CNT,
but blindly applies strlen() to the read buffer.
Is the the case ?

The second question:
It seems as if the whole asyn framework is designed to handle
octets as NUL-terminated strings, and NUL-terminated strings
as octets,
Because strlen() is used in the parameter library, there
is now way to handle binary data anyway.
(Otherwise I would suspect that we don't need strlen() at all... )
As this seems to be the case, it looks for me as if the
asyn framework only handles NUL terminated strings today,

And the write function can safely treat the maxChars parameter,
like this, re-using my_strnlen() from
asyn/devEpics/devAsynOctet.c

extern "C" {static asynStatus writeOctet(void *drvPvt, asynUser *pasynUser,

{
    asynPortDriver *pPvt = (asynPortDriver *)drvPvt;
    asynStatus status;
    size_t len = my_strnlen(value, maxChars);

    if (len > maxChars) len = maxChars;

    pPvt->lock();
    status = pPvt->writeOctet(pasynUser, value, len, nActual);
    pPvt->unlock();
    return(status);
}}

What do I miss ?






On 07/24/2016 02:42 AM, Mark Rivers 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>

asynPortDriver is now doing it that way on read operations.

Mark



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

But it seems to me that what you are requesting is what creates the need for drviers to require two paths and to somehow intuit which one to take.
I think that we’re in agreement that sending null characters to a device is a bad idea, right?  If so, then if the stringout record included the trailing null in the request count how could a driver know that in this case it should strip the trailing null when in the case of being called from a waveform record it should send the full request?

I think the existing behaviour is right.  Drivers send the actual request count (which in the stringout case does not include the terminator).  If a waveform record is being used to handle long strings writers should not include the trailing terminator in the request count.  This is where I think that caput -S is now doing things incorrectly.

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

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.

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 Eric Norum

RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers

Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum

RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers

Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum

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 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