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
<2012>
2013
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|