[Development] integer bug in Qt4.8.x

Samuel Rødal samuel.rodal at digia.com
Wed Mar 6 12:25:32 CET 2013


On 03/06/2013 11:38 AM, Thomas Senyk wrote:
> Hi,
>
> I think I stumbled over a bug in Qt4.8.x - QtDeclarative, but I wanted to
> asked for opinions first.
>
> First of all: This is not happening in Qt5 (neither QtQuick2.0 nor QtQuick
> 1.1)
>
> This seems to only happen on ARM... at least I couldn't reproduce on any x86
> machine I tried.
> The ARM system I tested on:
>    - imx6
>    - yocto based rootfs, sysroot and toolchain
>    - Qt5 built using mkspecs/devices/linux-imx6-g++ (not haven the bug)
>    - Qt4 built with my own mkspec based on the Qt5 device-mkspec
>    - Qt4/5 source-code from git with a most recent checkout
>
>
>
> The bug:
>
> It's about imprecise 'int' in QtQuick1.1 / JS (only Qt4!)
> A code snipped triggering it would be:
>
> property int ex: 0
>
> Component.onCompleted:
> {
>      var tmp;
>      var c = 1;
>
>      for ( tmp = ex + 1; /*forever*/; tmp++ )
>      {
>          if ( tmp !== ( ex + 1 ) )
>          {
>              console.log( "error: " + tmp + " != " + ex + " + 1" );
>          }
>
>          c = c+1;
>
>          if ( c > 100000 )
>          {
>              console.log( tmp );
>              c = 1;
>          }
>
>          ex = tmp;
>      }
>
> }
>
>
> The log looks like:
>
> ...
> 8200000
> 8300000
> error: 8388610 != 8388610 + 1
> error: 8388612 != 8388612 + 1
> error: 8388614 != 8388614 + 1
> error: 8388616 != 8388616 + 1
> ...
>
>
> where 8388610 == 0x800002
>
> For me it looks a little bit like some sort of floating-point accuracy
> problems ... or a casting-error ... ?
>
>
> Greets
> Thomas

Numbers in JavaScript are defined to be implemented as floating point. 
So I would expect the loop to end up printing error at some point. 
However, a JavaScript implementation is supposed to use double precision 
floating point numbers, in which case the loop would run for a really 
long time before printing out such an error (double can exactly 
represent all 32-bit integers).

However, with single precision floating point numbers you hit the 
problem a lot sooner, and this C program, using single precision 
floating point, shows the error happening at 16777216:

#include <stdio.h>
int main(int argc, char **argv)
{
     volatile float value = 1;
     volatile int v1, v2;
     do {
         v1 = value;
         v2 = (float)(value + 1.0);
         value = v2;
     } while (v1 != v2);
     printf("%d %d\n", v1, v1 / 2);
}

So there's still something strange going on, since 16777216 is two times 
8388608, which is where the error manifests in your example. Not sure 
what the explanation of that is, but at least I guess we can assume that 
the JavaScript engine used for QML in Qt 4 might use float (probably 
when qreal is float) and thus is not fully compliant.

--
Samuel



More information about the Development mailing list