PDA

View Full Version : Dereferencing for qFromBigEndian, some platforms problem



Krzysztow
7th December 2011, 19:27
Good evening,

I am writting application that communicates via bacnet protocol. This protocol uses a network byte order (big endian) for streaming data. When parsing, I have to interpret some bytes of received (and then send, but it's not an issue now) data as different types. For instance, for getting an quint16 from a data at pointer (quint8*)ptr, I use this kind of code


int Decoder::uint16FromRaw(quint8 *ptr, *quint16 result) {
Q_CHECK_PTR(ptr);
(*result) = qFromBigEndian(*(quint16*)ptr);
return sizeof(quint16);
}


And it works on my computer, however when I compile it for an embedded device, it doesn't. I added some qDebugs to see what is the problem:


int Decoder::uint16FromRaw(quint8 *ptr, *quint16 result) {
Q_CHECK_PTR(ptr);
quint16 toConv = *(quint16*)ptr;
qDebug()<<"A 0x"<<*ptr<<*(ptr+1)<<"is represented as 0x"<<hex<<toConv;
(*result) = qFromBigEndian(*(quint16*)ptr);
qDebug()<<"Converted 0x"<<*ptr<<*(ptr+1)<<"to"<<*((quint8*)result)<<*(((quint8*)result)+1)<<"was given 0x";
return (sizeof(quint16));
}


On my computer output is as expected.

A 0x 0 6 is represented as 0x 600
Converted 0x 0 6 to 6 0 was given 0x 600
But, on the device, I get:

A 0x 0 6 is represented as 0x 1
Converted 0x 0 6 to 0 1 was given 0x 1

So the problem is already in the line of ptr casted to quint16. Why? We are sure, there are bytes 0 and 6 following.

My both devices are little endian ones, linuxes. Has anyone any idea? Maybe this is some optimisation? I have no idea :/

Thank You. Best regards,
Krzysztof.