floating point encoders/decoders need redesign

[open62541]

floating point encoders/decoders need redesign

[uleon]

endian-agnostic decoders seem to work for regular numbers. Inf/Nan/etc missing but that's a simple 4/8-byte pattern matching issue. Has anybody got an idea for endian-agnostic decoders?

[Stasik0]

ahm, just an idea, why not using htonl and htonf functions to convert to big-endian and then work with that order? (a htonf is here: http://stackoverflow.com/a/10621440/383834)... using network functions we will not have to rely on compiler switches

[uleon]

@stasik: you mean something like

union { UA_Byte i[8]; double d; } tmp;
tmp.d = htonf(value); // convert to standard network big endian 
dst[*pos+0] = tmp.i[7]; ...; dst[*pos+7] = tmp.i[0]; // and eventually to opc ua's little endian

[Stasik0]

Hmmmm.... seems not to be very elegant...

Am 08.04.2014 um 20:16 schrieb uleon [email protected]:

@stasik: you mean something like

union { UA_Byte i[8]; double d; } tmp;
tmp.d = htonf(value); // convert to standard network big endian
dst[_pos+0] = i[7]; ...; dst[_pos+7] = i[0]; // and eventually to opc ua's little endian
—
Reply to this email directly or view it on GitHub.

[jpfr]

Why not let the precompiler deal with it? Autoconf has AC_C_BIGENDIAN. So we can set our own flag without relying on some nonstandard compiler extension.
Just 4 ifdef/ifndef/endifs around the numeric types and every architecture becomes as fast as possible.

[uleon]

I'd like to suggest to call the decoders of UA_UInt32 and UA_UInt64 with a casted pointer. This would work for all architectures that have IEEE745-floats with biased exponents in the same byte order as their ints. PDP would be out at the moment which I consider no problem because I've run out of 8"floppy disks as well.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.