QString::toShort problem

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
0_1530172437505_306d84bf-e9ce-4724-acc5-5efc6bd718b5-image.png

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?

jsulm

@JonB said in QString::toShort problem:

the implementation of QString::toShort() is not static_cast<short>(QString::toUShort())

I never said that

JonB

@jsulm
But you're asking why qDebug() << (short)0xFFFE; prints -2. And I'm saying that's because of the way "cast-to-short" works in C++, which is simply not what the implementation of Qt's QString::toShort() does or purports to do.

Basically, "cast-to-short" ((short)) has no concept ever of "overflow/error", but QString::toShort() does have a concept of "overflow/error", and that's why they work differently. They are not intended to be equivalent.

[I am beginning to feel the need for @kshegunov 's moral support here, because I feel I am being attacked ( :( ) and it is indeed all to do with the overflowing he mentioned in his earlier reply.]

jsulm

@JonB What overflow error do you mean? 0xFFFE is a valid short number in both cases: signed and unsigned.

kshegunov

Hey, let's do it the russian way and settle this outside, huh? Take a breath people.

@jsulm
Johann, you're wrong simply because "0xFFFE" is not a negative number, but a string, that simple. I know that in 2's complement for short this is -2, but that's if you go to the actual implementation of the negative numbers. The fact of the matter is there have been implementations that do not use integer complements. This string is not a binary representation, that is all, so don't expect the function to assume it should convert in binary-like way! Otherwise, as Jonas pointed out earlier "0xFFFFFFFFFFE" should just expand to -2 as well due to truncations.

JonB

@jsulm

@JonB What overflow error do you mean? 0xFFFE is a valid short number in both cases: signed and unsigned.

0xFFFE as a bit-pattern is indeed a valid signed or unsigned bit-pattern for a short. But as a string to parse, for QString::toUShort() it's valid (65,534, which is OK for ushort), but for QString::toShort() it's a positive number greater than the positive limit of 32,767 for a short ("overflow").

JonB

@kshegunov said in QString::toShort problem:

Hey, let's do it the russian way and settle this outside, huh? Take a breath people.

LOL! Phew, that's what I needed from you! I thought you might be Russian: are you "Mafiosa", could you send some "heavies" round to @jsulm for me...? ;-)

jsulm

@kshegunov "Hey, let's do it the russian way and settle this outside, huh?" - wait a bit I need to collect some more guys to have better arguments :-)
OK, I see. But actually Qt "knows" for which platform it was built (2's complement or something else) and could interpret such strings accordingly. I guess Qt devs wanted to go safe route :-)
@Bart_Vandewoestyne I would say @kshegunov suggested the correct solution:

short hex2 = static_cast<short>(str2.toUShort(&ok2, 16));

JonB

@J.Hilk said in QString::toShort problem:

QString s("0xFFFFFFFFFFFFFFFE"); bool ok;
long lg = s.toLongLong(&ok,16);

What is it in the implementation of qint64 QString::toLongLong() which makes this set ok=false instead of returning -2 ?

J.Hilk

@JonB
thatsa a rapidhole down QString and QLocal ... 😨😨

Still to early in the morning to explore that ;-)

kshegunov

@JonB said in QString::toShort problem:

I thought you might be Russian: are you "Mafiosa", could you send some "heavies" round to @jsulm for me...?

No, I'm not russian, but let's assume I know a guy who knows a guy, who knows a guy ... ;)

What is it in the implementation of qint64 QString::toLongLong() which makes this set ok=false instead of returning -2 ?

https://code.woboq.org/qt5/qtbase/src/corelib/tools/qlocale.cpp.html#_ZNK11QLocaleData15numberToCLocaleE11QStringView6QFlagsIN7QLocale12NumberOptionEEP15QVarLengthArrayIcLi256EE

JonB

@kshegunov
The link you provide, for QLocaleData::numberToCLocale(), is for outputting internal numbers -> external strings. For QString::toLongLong() I am looking for function code which is for inputting external string -> internal number, and see why 0xFFFFFFFFFFFFFFFE is causing a conversion error?

kshegunov

It's part of the implementation - the checking part. Sorry forgot the first link x_x.
See here:
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qlocale.cpp.html#_ZNK11QLocaleData16stringToLongLongE11QStringViewiPb6QFlagsIN7QLocale12NumberOptionEE
and here:
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qlocale.cpp.html#_ZN11QLocaleData19bytearrayToLongLongEPKciPb

J.Hilk

@JonB
no, @kshegunov is right,

toLongLong calls, stringtolonglong

qlonglong QLocaleData::stringToLongLong(QStringView str, int base, bool *ok,
                                        QLocale::NumberOptions number_options) const
{
    CharBuff buff;
    if (!numberToCLocale(str, number_options, &buff)) {
        if (ok != 0)
            *ok = false;
        return 0;
    }
    return bytearrayToLongLong(buff.constData(), base, ok);
}

that calls numberToCLocale

and uses the resulting char array to call bytearrayToLongLong


qlonglong QLocaleData::bytearrayToLongLong(const char *num, int base, bool *ok)
{
    bool _ok;
    const char *endptr;
    if (*num == '\0') {
        if (ok != 0)
            *ok = false;
        return 0;
    }
    qlonglong l = qstrtoll(num, &endptr, base, &_ok);
    if (!_ok) {
        if (ok != 0)
            *ok = false;
        return 0;
    }
    if (*endptr != '\0') {
        // we stopped at a non-digit character after converting some digits
        if (ok != 0)
            *ok = false;
        return 0;
    }
    if (ok != 0)
        *ok = true;
    return l;
}

long long
qstrtoll(const char * nptr, const char **endptr, int base, bool *ok)
{
    *ok = true;
    errno = 0;
    char *endptr2 = 0;
    long long result = qt_strtoll(nptr, &endptr2, base);
    if (endptr)
        *endptr = endptr2;
    if ((result == 0 || result == std::numeric_limits<long long>::min()
         || result == std::numeric_limits<long long>::max())
            && (errno || nptr == endptr2)) {
        *ok = false;
        return 0;
    }
    return result;
}

like I said, a rRabbit Hole

JonB

@J.Hilk
OK, in that case, what's the implementation of qt_strtoll(), when performed on 0xFFFFFFFFFFFFFFFE? I'm expecting it to return -2, but I'm guessing it returns std::numeric_limits<long long>::min() (or maybe ::max()), but why?