EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Size encoding
From: Benjamin Franksen <[email protected]>
To: EPICS Core Talk <[email protected]>
Date: Wed, 16 May 2018 14:55:15 +0200
Here is the corresponding code from pvDataJava:

(https://github.com/epics-base/pvDataJava/blob/master/src/org/epics/pvdata/misc/SerializeHelper.java#L17)

/**
 * Serialize the specified array size into the specified buffer.
 * @param s       size to encode
 * @param buffer  the buffer to be serialized into
 */
private final static void writeSize(final int s, ByteBuffer buffer) {
    if (s == -1)                    // null
        buffer.put((byte)-1);
    else if (s < 254)
        buffer.put((byte)s);
    else
        buffer.put((byte)-2).putInt(s);    // (byte)-2 + size
}

BTW. What I personally find most striking about this is how the
documentation tells us only those things anyone with an IQ above 20 can
guess from the names of class, method, and parameters, while carefully
avoiding to mention things a human reader might find interesting, such as

* where do I find a specification of the encoding?
* what happens if I pass a negative size?
* are there any other exceptional conditions?

Cheers
Ben

On 05/15/2018 03:46 PM, Ralph Lange wrote:
> Hi Bruno,
> 
> I agree that the C++ implementation seemingly uses -1 in the first byte to
> encode "empty" and -2 to encode "string of size >= 2^8-2".
> Houston, we have a problem.
> 
> (The value you are missing in the third case of the spec is explicitly
> mentioned there as 2^31-1.)
> 
> Cheers,
> ~Ralph
> 
> 
> On Tue, May 15, 2018 at 3:13 PM Bruno Martins <[email protected]> wrote:
> 
>> Hi,
>>
>> I was taking a look at how messages are de/serialized by pvData and
>> pvAccess and I think there is an inconsistency between the spec and the
>> implementation regarding how sizes are encoded.
>>
>> The spec says, basically [1]:
>>
>> If size < 2^8-1, encode byte directly
>> If size < 2^31-1, encode -1 as byte and then size as signed 32-bit integer
>> If size < 2^63-1, encode -1 as byte, then a positive 32-bit int (which
>> value? -1?), then size as a signed 64-bit integer.
>>
>> The implementation (C++) does [2]:
>>
>> If size == -1, encode -1 as byte (what is this used for?)
>> If size < 2^8 - 2, encode size directly as byte
>> Else encode -2 as byte, size as signed 32-bit integer
>>
>>
>>
>> [1]
>> http://epics-pvdata.sourceforge.net/pvAccess_Protocol_Specification.html#dataEncoding:sizes
>>
>> [2]
>> https://github.com/epics-base/pvDataCPP/blob/207efca15cf471bbc2990cbd336000e04dcfcd22/src/misc/serializeHelper.cpp#L34

Attachment: signature.asc
Description: OpenPGP digital signature


Replies:
Re: Size encoding Michael Davidsaver
References:
Size encoding Bruno Martins
Re: Size encoding Ralph Lange

Navigate by Date:
Prev: random half finished features Michael Davidsaver
Next: Build failed in Jenkins: epics-base-3.14 #287 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Size encoding Ralph Lange
Next: Re: Size encoding Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 18 May 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·