[BUG]Conversion from signed number to hexadecimal string?
-
int value = -1; QString str; str = QString::number(value, 16); // expect "ffffffff" got "ffffffffffffffff" short value2 = -32768; str = QString("%1").arg(value2, 0, 16); //expect "8000" got "ffffffffffff8000"
Why do Qt automatically perform 64bit sign extension before convert to string? Is this a bug?
It is very weird that you got string representation of 64 bit number while all you have is a byte even though they have same meaning then need to chop off the prefix
str = QString("%1").arg(value, 0, 16).right(sizeof(value)<<1);
-
int value = -1; QString str; str = QString::number(value, 16); // expect "ffffffff" got "ffffffffffffffff" short value2 = -32768; str = QString("%1").arg(value2, 0, 16); //expect "8000" got "ffffffffffff8000"
Why do Qt automatically perform 64bit sign extension before convert to string? Is this a bug?
It is very weird that you got string representation of 64 bit number while all you have is a byte even though they have same meaning then need to chop off the prefix
str = QString("%1").arg(value, 0, 16).right(sizeof(value)<<1);
Hi @adonezid,
int value = -1;
QString str;
str = QString::number(value, 16); // expect "ffffffff" got "ffffffffffffffff"I would expect
str
to be"-1"
, which I get with Qt 6.5, but with Qt 5.15 I see the same surprising behaviour as you reported. Looks like it was fixed in Qt 6.0 as part of QTBUG-53706.Cheers.
-
Hi @adonezid,
int value = -1;
QString str;
str = QString::number(value, 16); // expect "ffffffff" got "ffffffffffffffff"I would expect
str
to be"-1"
, which I get with Qt 6.5, but with Qt 5.15 I see the same surprising behaviour as you reported. Looks like it was fixed in Qt 6.0 as part of QTBUG-53706.Cheers.
@Paul-Colby
Yep, that report describes the old behaviour aswhen the value is negative, handling sign gracefully, not casting via unsigned long long.
Hence behaviour from OP. Looks like there was quite a bit of "differences of opinion" there :)
-
@Paul-Colby
Yep, that report describes the old behaviour aswhen the value is negative, handling sign gracefully, not casting via unsigned long long.
Hence behaviour from OP. Looks like there was quite a bit of "differences of opinion" there :)