2

There's this piece of code that works fine in QtCreator (on Windows 7) but behaves differently when running on a linux based embedded platform and I'm not sure how to begin debugging it.

Here's the code in question:

QByteArray c(1, char(0x00));
bool bOk = false;
int intVal= c.toHex().toInt(&bOk,16);
if(bOk) {
    qDebug() << "conversion success \t" << intVal;
}
else {
    qDebug() << "conversion failed \t" << intVal;
}

In QtCreator (running in Windows) this works fine and intVal has the value 0, as expected.

However, when compiled and run in the embedded Linux environment, the conversion fails and bOk is false.

Strangely for c = 0xFF it works properly in both environments.

Details

Qt Version : 4.7

Environment 1 : Windows

  • OS : Windows 7
  • Environment : Qt-Creator
  • sizeof(int) = 4 bytes
  • Processor : It's an old machine with an Intel Pentium Core-2 Duo (Unfortunately I can't remember the exact model). They're all x86 architecture though so that would be little-endian.

Environment 2 : Linux

  • OS : A custom Embedded Linux (not sure which version or how to find out)
  • Environment : A cross-compiled program that is running on this target.
  • sizeof(int) : 4 bytes
  • Processor Endianess : ARM7, so that's BE-32 Endianess (according to this answer)
Community
  • 1
  • 1
jlouzado
  • 442
  • 3
  • 17

1 Answers1

0

If i understand correctly, you're saying BE-32 Endian (big endian word invariance) is being used on Linux, but little endian on the Intel processor.

You're also taking 1 byte and converting that to 2 with toInt() before converting that to Hex

Without being able to debug this myself, I'm guessing that the conversion with different endian may be the problem here, so suggest using the endian conversion routines, as documented here.

You can read about different endian in these answers.

Community
  • 1
  • 1
TheDarkKnight
  • 27,181
  • 6
  • 55
  • 85
  • The byte of data is stored in a QByteArray, and the conversion to Hex (i.e. toHex()) is done before the toInt(). Is that relative order important an important factor to consider? – jlouzado Apr 02 '14 at 11:11
  • I'm not sure that you even need to call toHex() here. If you initialise the array with 0x0 or 0xFF, the 0x implicitly means hex. Reading the documentation it states that unless you're using raw bytes with fromRawData(), it stores an additional '/0' to allow the byte array to work with QString. However, it doesn't mention if this occurs with the constructor which you're using: QByteArray(int size, char ch). I suggest investigating this too. – TheDarkKnight Apr 02 '14 at 12:37