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: Andrew Johnson <[email protected]>
To: Mark Rivers <[email protected]>, "Tech-talk" <[email protected]>
Date: Tue, 13 Nov 2012 16:56:19 -0500
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.

- Andrew
-- 
READ CAREFULLY. By reading this email, you agree, on behalf of your
employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrink-wrap, click-wrap, browse-wrap, confidentiality, non-disclosure,
non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I
have entered into with your employer, its partners, licensors, agents
and assigns, in perpetuity, without prejudice to my ongoing rights
and privileges. You further represent that you have the authority to
release me from any BOGUS AGREEMENTS on behalf of your employer.

Replies:
Re: Long string support in CA clients and device support Eric Norum
RE: Long string support in CA clients and device support Mark Rivers
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

Navigate by Date:
Prev: Re: Long string support in CA clients and device support Eric Norum
Next: Re: Long string support in CA clients and device support Eric Norum
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 Eric Norum
Next: Re: Long string support in CA clients and device support Eric Norum
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 ·