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