Qt-interest Archive, July 2006
char values get printed as 4294967198
Message 1 in thread
Hi,
I've got a very strange problem. In my application I communicate via
QextSerialport (http://qextserialport.sourceforge.net/) with a serialport.
The methode getChar(char * c) reads a char from the device.
When I print the value qDebug("value is: %u", readChar) it sometimes
prints values very large values (for example: 4294967198). In the other
cases it prints the "normal" value in the range of 0-255. As far as I
can tell there are no values printed in the range of 255 - 4294967000.
if I check for those large values for example:
if(c > 254) qDebug("VeryLarge");
the debugline never gets printed.
All typeconversions leading to printable characters seem to print the
large values when they occur.
Can anybody explain this and/or point me to a solution?
Thanks for your help,
Onno
Some extra information:
I am using QT4.1 and GCC 4.0.3 on Ubuntu 6.06 Dapper Drake (kernel
2.6.15-26 on an amd64)
The extracted which most directly shows the problem is printed below (it
is part of Qextserialport version 1.0)
bool Posix_QextSerialPort::getChar(char * c)
{
LOCK_MUTEX();
bool retVal=false;
if (portOpen) {
char readChar=0;
retVal = Posix_File->getChar(&readChar);
if(retVal == false) {
lastErr=E_READ_FAILED;
} else {
if (readChar > 254)
qDebug("VeryLarge");
qDebug("value is: %u", readChar);
*c = readChar;
}
}
UNLOCK_MUTEX();
return retVal;
}
--
[ signature omitted ]
Message 2 in thread
Onno wrote:
> I've got a very strange problem. In my application I communicate via
> QextSerialport (http://qextserialport.sourceforge.net/) with a serialport.
> The methode getChar(char * c) reads a char from the device.
> When I print the value qDebug("value is: %u", readChar) it sometimes
> prints values very large values (for example: 4294967198). In the other
> cases it prints the "normal" value in the range of 0-255. As far as I
> can tell there are no values printed in the range of 255 - 4294967000.
This looks like a signed/unsigned issue. 4294967198 in hex is 0xFFFF FF9e, which is the same as -98 in a 32-bit signed integer.
Note that the char type is signed; I think that getChar() is returning 0x9e (which is negative in an 8-bit signed value).
The %u format is expecting an unsigned integer (probably 32 bits, given the output), so your compiler is probably casting the char to an int and then qDebug (as will all printf-like functions) is reading it as an unsigned int.
If you change the char to an unsigned char, or use %d rather than %u, it should print out the proper value.
-Andrew
--
[ signature omitted ]
Message 3 in thread
On Mon, 31 Jul 2006 12:00:15 -0500, Andrew Vick wrote:
> Onno wrote:
>> I've got a very strange problem. In my application I communicate via
>> QextSerialport (http://qextserialport.sourceforge.net/) with a
>> serialport. The methode getChar(char * c) reads a char from the device.
>> When I print the value qDebug("value is: %u", readChar) it sometimes
>> prints values very large values (for example: 4294967198). In the other
>> cases it prints the "normal" value in the range of 0-255. As far as I
>> can tell there are no values printed in the range of 255 - 4294967000.
>
> This looks like a signed/unsigned issue. 4294967198 in hex is 0xFFFF
> FF9e, which is the same as -98 in a 32-bit signed integer.
>
> Note that the char type is signed; I think that getChar() is returning
> 0x9e (which is negative in an 8-bit signed value).
>
> The %u format is expecting an unsigned integer (probably 32 bits, given
> the output), so your compiler is probably casting the char to an int and
> then qDebug (as will all printf-like functions) is reading it as an
> unsigned int.
>
> If you change the char to an unsigned char, or use %d rather than %u, it
> should print out the proper value.
It looks like you are right indeed. Using %d prints "normal" values (I
might be off by one) -128 and 127. Compiling the complete sources with the
-funsigned-char flag seems to do a lot as well.
Thanks, with your supplied input I should be able to get it all working.
Maybe I should stick by the uint8_t types supplied by gcc for this kind of
job.
Thanks, again,
Onno
--
[ signature omitted ]
