QString::toShort problem



  • According to https://www.scadacore.com/tools/programming-calculators/online-hex-converter/ the 'HexString Input' 0014 is the value 20 in INT16 Big Endian representation. And yes, this works:

    QString str1 = "0014";
    bool ok1;
    short hex1 = str1.toShort(&ok1, 16);
    

    According to the same website, the 'HexString Input' FFFE is the value -2 in INT16 Big Endian representation. However, with my Qt 4.8.7 and for the conversion

    QString str2 = "FFFE";
    bool ok2;
    short hex2 = str2.toShort(&ok2, 16);
    

    hex2 has the value 0 and ok2 is false, so the conversion failed. Why don't I get -2 and how should I convert "FFFE" so that it results in -2?


  • Qt Champions 2017

    Use QString::toUShort:

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


  • @kshegunov said in QString::toShort problem:

    Use QString::toUShort:

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

    Nice! That seems to work, but I have no clue why it works :-) What I don't understand is that the value -2 is a SIGNED integer with representation FFFE, so why is it then necessary to first interpret the FFFE representation as that for an UNSIGNED short, and then cast to short??? Is that a workaround for a bug in QString::toShort? Or should I freshen up my knowledge of two's complement to understand this trick? ;-)



  • @Bart_Vandewoestyne
    There appears to be a difference in behaviour between toShort() and toUShort() which the documentation does not mention and @kshegunov is fiendlishly taking advantage of with internal knowledge :)


  • Moderators

    FFFE is simply to big for a signed short ...



  • @Christian-Ehrlicher said in QString::toShort problem:

    FFFE is simply to big for a signed short ...

    Why? Considering Visual Studio 2015 (and I assume also a lot of other compilers), the range for (signed) short is –32,768 to 32,767 (see https://msdn.microsoft.com/nl-be/library/s3f49ktz.aspx). The value -2 (represented by FFFE = two's complement) fals nicely into that range. So that's why I was expecting to be able to go from "FFFE" to -2 using QString::toShort()...



  • @Bart_Vandewoestyne
    Because 0xFFFE is 65,534. It fits in an unsigned short range, but overflows the signed short's maximum positive value of 32,767. That's what @Christian-Ehrlicher is saying.

    You are assuming that QString::toShort() will treat the string 0xFFFE as meaning exactly the same thing as -2, but it doesn't. It regards it as a positive number which is beyond the range of signed shorts, not as an alternative way of writing -2.


  • Moderators

    @JonB I disagree.
    Complement on two for 2:

      0000 0010
      1111 1101
    + 0000 0001
      1111 1110
    

    So, -2 is 1111 1110 or 0xFE - why should this not feet into a signed short?
    "You are assuming that QString::toShort() will treat the string 0xFFFE as meaning exactly the same thing as -2, but it doesn't" - why should toShort() not treat 0xFE as -2?


  • Qt Champions 2017

    @jsulm said in QString::toShort problem:

    @JonB I disagree.

    You shouldn't. ;)

    why should toShort() not treat 0xFE as -2?

    Quite simply because you don't have a fixed-size data field to work with as input. Why should toShort assume that you meant exactly the binary representation. You could've just as well had a data that's too big to fit the type. Say I'm reading some input and I'm trying to get it into a short. Suddenly due to an error or by whatever chance I get a number that's too big for my short, but instead of overflowing the toShort would give me an invalid value. It doesn't make sense that the person who implemented toShort would just jump the gun on such an assumption.
    And lastly, what should we do with overflows of this kind - 0x100FF, shall toShort return 255 in this case?


  • Moderators

    @kshegunov said in QString::toShort problem:

    Why should toShort assume that you meant exactly the binary representation

    Maybe I'm still sleeping and oversee something. What else should it assume? If I say its hex and pass FFFE - how does toShort() interpret it?
    0x100FF is too big for a short and toShort() should return 0/false (and it does). But FFFE is a valid signed short number.



  • @jsulm said in QString::toShort problem:

    @kshegunov said in QString::toShort problem:

    Why should toShort assume that you meant exactly the binary representation

    Maybe I'm still sleeping and oversee something. What else should it assume? If I say its hex and pass FFFE - how does toShort() interpret it?
    0x100FF is too big for a short and toShort() should return 0/false (and it does). But FFFE is a valid signed short number.

    @jsulm I completely agree! (although I have the same feeling about sleeping and maybe overseeing something ;-) Maybe it's time to dive into the Qt 4.8.7 source and investigate why QString::toShort() is failing on "FFFE"? (does Qt 5.X also fail on that btw?)


  • Qt Champions 2017

    @jsulm said in QString::toShort problem:

    But FFFE is a valid signed short number.

    No it isn't, and that's the point. Start doing the math in your head and see for yourself:

    E * 1 + F * 16 + F * 16^2 + F * 16^3
    

    And the last term overflows, which overflow is caught and voila!
    If you have

    char z = 127;
    

    then:

    z += 1;
    

    Is overflowing, no matter whether the value you get is "correct".


  • Moderators

    @kshegunov I still don't get it.
    What is the representation of -2 as signed short? Isn't it 0xFFFE?

      0000 0000 0000 0010 - 2
      1111 1111 1111 1101 - invert
    + 0000 0000 0000 0001 - add 1
      1111 1111 1111 1110
    -> 0xFFFE
    

  • Moderators

    OK, here's an exercise to settle the debate. First, assume that QString::toShort() behaves exactly as you expect.

    What should each QString (p_*) be initialized to, in order to get 32 for every output line?

    QString p_oct, p_dec, p_hex, p_r32;
    
    // ... Initialize QStrings here ...
    
    qDebug() << p_dec.toShort(nullptr, 10); // Returns 32
    qDebug() << p_hex.toShort(nullptr, 16); // Returns 32
    
    qDebug() << p_oct.toShort(nullptr, 8);  // Returns 32
    qDebug() << p_r32.toShort(nullptr, 32); // Returns 32
    

    Next, what should each QString (n_*) be initialized to, in order to get -32 for every output line?

    QString n_oct, n_dec, n_hex, n_r32;
    
    // ... Initialize QStrings here ...
    
    qDebug() << n_oct.toShort(nullptr, 8);  // Returns -32
    qDebug() << n_dec.toShort(nullptr, 10); // Returns -32
    qDebug() << n_hex.toShort(nullptr, 16); // Returns -32
    qDebug() << n_r32.toShort(nullptr, 32); // Returns -32
    

    Decide on your answer for all 8 strings first, then post your answer here.



  • @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).



  • 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


  • Moderators

    @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.



  • @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?!



  • @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.


  • Moderators

    @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.



  • @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....


  • Moderators

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


  • Moderators

    @JonB Passing 0xFFFFFFFE returns 0



  • @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)



  • @jsulm

    @JonB Passing 0xFFFFFFFE returns 0

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


  • Moderators

    @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.



  • @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
    


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


  • Moderators

    @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)?


  • Moderators

    @JonB

    qDebug() << (short)0xFFFE;
    

    prints -2 as expected



  • @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.


  • @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)



  • @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.


  • Moderators

    @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?


  • Moderators

    @JonB said in QString::toShort problem:

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

    I never said that



  • @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.]


  • Moderators

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


  • Qt Champions 2017

    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.



  • @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").



  • @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...? ;-)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.