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  <20122013  2014  2015  2016  2017  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Long string support in CA clients and device support
From: Eric Norum <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Tech-talk <[email protected]>
Date: Tue, 13 Nov 2012 14:54:00 -0800
On Nov 13, 2012, at 1:56 PM, Andrew Johnson <[email protected]> wrote:

> Hi Mark,
> 
> On 2012-11-13 Mark Rivers wrote:
>> 
>> So do we agree with Andrew's recommendation that NORD should including the
>> trailing Nil, or should NORD be the actual number of elements that were
>> read, and clients must be fixed to handle this if they want to use long
>> string support?
> 
> Passing around long strings that don't have (or count) a terminating Nil byte 
> is inherently risky, although the danger is more likely to be annoying 
> (appending garbage or old text to the current text) than to induce crashes in 
> the IOC.
> 
> An aSub record subroutine is a client, and it's very easy for the subroutine's 
> author to not realize that the long string in their record's input field may 
> not be Nil-terminated.  The code that reads the input link into that field is 
> generic and can't add the Nil.  If the code calls strlen() on the buffer or 
> passes it into sprintf() without doing the termination dance it's going to 
> count the garbage.
> 
> I understand Eric's desire to not add zero bytes to data that Asyn reads in 
> through a serial or network port and that is obviously essential, but that's 
> not what you're proposing to do anyway.  If I've read your message correctly 
> asynPortDriver parameter strings are coming from internal sources, they are 
> not providing raw data from the port.  By counting the Nil when it is already 
> present you are reducing the work that the author of a 1-off aSub subroutine 
> has to do, and making the IOC code more robust.

So how does the author of a client (aSub subroutine or anything else) determine the meaning of NORD with the proposed change in place?
How does the author determine whether the the source of a an array of characters is something that appends a nil or something like a serial/network port that does not?   Maybe the source might even change at run time.
Mucking with the semantics of NORD is a BadIdea (™, IMHO).

-- 
Eric Norum
[email protected]



Replies:
Re: Long string support in CA clients and device support Andrew Johnson
References:
Long string support in CA clients and device support Andrew Johnson
RE: Long string support in CA clients and device support Mark Rivers
RE: Long string support in CA clients and device support Mark Rivers
Re: Long string support in CA clients and device support Andrew Johnson

Navigate by Date:
Prev: Re: Long string support in CA clients and device support Andrew Johnson
Next: Re: Long string support in CA clients and device support Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Long string support in CA clients and device support Andrew Johnson
Next: Re: Long string support in CA clients and device support Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·