Note that there are some explanatory texts on larger screens.

plurals
  1. POClosed source library - endianness - negative -1 is read as 0 when deserializing
    text
    copied!<p>I am reading some floats from a binary xml and deserealize them into a struct containing 4 floats (32 bit floats to be exact). All the values get read correctly, except for those that are -1. </p> <p><em>Is this an endian-related issue?</em></p> <p>What should I look for if <code>-1</code> is converted to <code>0</code> and <em>every</em> other value is correctly deserialized? (I mean, is there an obvious, common mistake or source for a mistake I should take into account?). I do not have any access to the library that does this and I can't provide you with any details since it's confidential.</p> <p>Before this question really gets closed, I'd like to post a small hint (no code due to a harsh NDA condition):</p> <ul> <li>the library I'm working with converts some binary data from an xml to its specific types</li> <li><p>it does this in a very ugly way: </p> <p>value = <em>(T</em>)srcBuffer; </p> <p>SwapByte(value);</p></li> <li><p><code>-1</code> is thus directly read and assumed to be in BigEndian format. Unfortunately, <code>-1</code> amounts to <code>somethingE-47</code> which is indeed a very small number in BigEndian format. The assembly instructions perform some quantization <em>and</em> round it to zero. The ulterior <code>SwapByte</code> instruction will thus get the wrong data and fail for this odd case. It is an architectural problem related to an IBM/PowerPC processor. </p></li> </ul> <p>Would a <code>memcpy</code> work better and avoid the ugly quantization artifact? I can't do the swapbyte before the conversion as I will surely deteriorate other parts.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload