EPICS Home

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: "J. Lewis Muir" <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Tech-talk <[email protected]>
Date: Thu, 15 Nov 2012 12:20:38 -0600
On 11/15/12 10:43 AM, Andrew Johnson wrote:
>> Another problem with including the NUL byte is that if I fetch a
>> waveform record's VAL field from another language, say Java, I now have
>> to do extra work by checking to see if the NUL byte is included and
>> throw it away if it is; it's a totally bogus character in this context.
> 
> You'll have to do that anyway, because if you point your Java client using the 
> $ field modifier at an 80-char CALC field or a link address you *will* get a 
> Nil byte in it that terminates the string.  With the current code that Nil 
> byte may be followed by non-Nil data from previous contents of that field 
> (because the field modifier code doesn't support dynamimc sizing yet anyway), 
> so code that converts a char array into a non-C string must stop at either the 
> first Nil or the end of the array.

Hi, Andrew.

Hmm...I didn't know that.  That's a bummer.  Still, I'd expect my
underlying Java CA library to handle that case for me so I wouldn't have
to deal with it in my Java client.

What happens for type DBF_STRING when it is *not* fetched as a
long-string?  Is it always just sent as 40 bytes and the client has to
figure out where the string ends based on where the NUL byte is?  I
would have thought a string would be sent over CA encoded as two parts:
an array of bytes (where each byte represents a DBF_CHAR) and the
length.  I would not expect the NUL byte to be in the array.  (But this
is just what I'd expect, I haven't looked at how CA actually encodes
anything.)

If a DBF_STRING includes the NUL byte over CA when *not* fetched as a
long-string, then I would think that fetching a long-string (by using
the '$' suffix) from a waveform record's VAL field would include a NUL
byte over CA also.

But for the case of just fetching an array of chars from a waveform
record's VAL field, I would not expect to get a NUL byte in that since
NORD is supposed to tell me the length.

Lewis

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 Andrew Johnson
Re: Long string support in CA clients and device support J. Lewis Muir
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