QString::toShort problem

[JonB]

@jsulm , @Bart_Vandewoestyne

I don't get what you don't get about: 0xFFFE is a positive overflow for parsing & storing into a ushort. Hence the behaviour.

One thing that is clear: the implementation of QString::toShort() is not static_cast<short>(QString::toUShort()), even if that might have been the way you were tempted to do it.

Nobody has looked at it "the other way round". I cannot test because I am Python/PyQt not C++, but what does

QString("-2").toUShort(&ok, 16)

return? In your theory it should be 0xFFFE, but I am "hoping"(!) it returns an error, just like QString("FFFE").toShort(&ok, 16) does?

Assuming that is the case, this means we do not have an ambiguity/duplication, whereby both FFFE and -2 strings can be parsed as the same number by toShort()/toUShort() (but 2 is the only way to write +2).

[J.Hilk]

toShort makes a toLongLong interpretation first and than casts it to short theres where the "error" comes from:

short QString::toShort(bool *ok, int base) const
{
    long v = toLongLong(ok, base);
    if (v < SHRT_MIN || v > SHRT_MAX) {
        if (ok)
            *ok = false;
        v = 0;
    }
    return (short)v;
}

toLongLong will return ‭65534‬, (0xFFFE in int64 is positve after all), and that is bigger than SHRT_MAX -> 0 and failed conversion

[jsulm]

@JonB said in QString::toShort problem:

In your theory it should be 0xFFFE

No, it would not, because -2 is not a hex number...
"I don't get what you don't get about: 0xFFFE is a positive overflow for parsing & storing into a ushort" - we are not talking about unsigned short, but signed short and 0xFFFE is the representation of -2.

[JonB]

@J.Hilk
In that case, try passing something like 0xFFFFFFFE or 0xFFFFFFFFFFFFFFFE for the string to toShort() and those who want -2 instead of error should get it?!

[JonB]

@jsulm

No, it would not, because -2 is not a hex number...

Yes it is! It's as much a hex number as some other base.

[jsulm]

@JonB said in QString::toShort problem:

In that case, try passing something like 0xFFFFFFFE or 0xFFFFFFFFFFFFFFFE for the string to toShort()

Come on - these numbers are NOT short. We should stay on topic.

[JonB]

@jsulm said in QString::toShort problem:

Come on - these numbers are NOT short. We should stay on topic.

I beg your pardon!? I am totally on topic. I was replying to @J-Hilk 's display of the code of QString::toShort(). Did you try what I suggested rather than dismissing it as OT? In view of the code shown, I am trying to suggest what 0xFFF.... string toShort() will accept as representing a negative number....

[JKSH]

Nobody wants to try my exercises... (sad face)

[jsulm]

@JonB Passing 0xFFFFFFFE returns 0

[J.Hilk]

@JonB
actually, no take a look at toLongLong

qint64 QString::toLongLong(bool *ok, int base) const
{
#if defined(QT_CHECK_RANGE)
    if (base != 0 && (base < 2 || base > 36)) {
        qWarning("QString::toLongLong: Invalid base (%d)", base);
        base = 10;
    }
#endif

    bool my_ok;
    QLocale def_locale;
    qint64 result = def_locale.d()->stringToLongLong(*this, base, &my_ok, QLocalePrivate::FailOnGroupSeparators);
    if (my_ok) {
        if (ok != 0)
            *ok = true;
        return result;
    }

    QLocale c_locale(QLocale::C);
    return c_locale.d()->stringToLongLong(*this, base, ok, QLocalePrivate::FailOnGroupSeparators);
}

I think, haven't looked stringToLongLong up, that here happens stirng lentgh magic, because every combinaion of FFF..E up to to 0xFFFFFFFE is interpretated as the uint value and everything above as -2 (as returning int64 value)

[JonB]

@jsulm

@JonB Passing 0xFFFFFFFE returns 0

Since QString::toLongLong() returns a qint64 (8 bytes, not 4), did you try 0xFFFFFFFFFFFFFFFE ?

[jsulm]

@JonB said in QString::toShort problem:

Since QString::toLongLong() returns a qint64 (8 bytes), did you try 0xFFFFFFFFFFFFFFFE ?

Returns 0 as well.
And I don't see why it should depend on the length.

[J.Hilk]

@JonB surprisingly enough

qDebug() << std::numeric_limits<int64_t>::min() << std::numeric_limits<int64_t>::max()
             << endl << (int64_t)0xFFFFFFFFFFFFFFFE;
 QString s("0xFFFFFFFFFFFFFFFE"); bool ok;
short sh =  s.toShort(&ok, 16);
qDebug() <<sh << ok;
long lg = s.toLongLong(&ok,16);
qDebug() << lg << ok;

returns:

-9223372036854775808 9223372036854775807 
-2
0 false
0 false

[JonB]

@jsulm
It would "depend on the length", as you put it, because as a 64-bit number 0xFFFFFFFE != 0xFFFFFFFFFFFFFFFE.

[jsulm]

@JonB I want to convert a signed short number not long or long long or ...
0xFFFE as signed short is -2 - do you agree (I mean independently from what Qt toShort() thinks it is)?

[jsulm]

@JonB

qDebug() << (short)0xFFFE;

prints -2 as expected

[JonB]

@jsulm
I believe the problem here is a confusion between "bit representation" and "string representation".

• It is undoubtedly, unambiguously true that, for signed short, 0xFFFE as a bit pattern is -2.
• However, for signed short, 0xFFFE as a string "could" be either -2 (which fits in a short) or 65,534 (which does not fit in a short). And QString::toShort() is taking the latter interpretation, and hence erroring.

[J.Hilk]

@jsulm said in QString::toShort problem:

@JonB

qDebug() << (short)0xFFFE;

prints -2 as expected

qDebug() << (short)0xFFFFFFFFFFFFFFFE;

prints also -2, would one expect that

actually yes, the first bytes are simply dropped x)

[JonB]

@jsulm said in QString::toShort problem:

@JonB

qDebug() << (short)0xFFFE;

prints -2 as expected

Yes, that's why I wrote earlier:

One thing that is clear: the implementation of QString::toShort() is not static_cast<short>(QString::toUShort()), even if that might have been the way you were tempted to do it.

[jsulm]

@JonB said in QString::toShort problem:

However, for signed short, 0xFFFE as a string "could" be either -2 (which fits in a short) or 65,534

No, signed short 0xFFFE is -2 even as string, because I'm calling toShort() not toUShort().
And why does

qDebug() << (short)0xFFFE;

print -2?