Fix sign-extension

If data[0] were > 128 (that is, if the full size, encoded in big endian
were > 2 GB), the result of the OR chain would be a negative int (due to
C integer promotion rules). We're shifting into the sign bit, which is
either implementation-defined behavior or, worse, undefined behavior.

This negative number is then sign-extended to ulong (64-bit on 64-bit
platforms), which then becomes a big number. This code was probably
written with only 32-bit in mind, where there would be no size extension
(sign or otherwise).

This isn't too bad because there's a size check for the max size of
QByteArray a few lines below, but we can fix it, so let's do it.

Found by Coverity, CID 22530.

Change-Id: I42e7ef1a481840699a8dffff1407ea6c22e1a0ec
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>

src/corelib/tools/qbytearray.cpp

@@ -578,8 +578,8 @@ QByteArray qUncompress(const uchar* data, int nbytes)
             qWarning("qUncompress: Input data is corrupted");
         return QByteArray();
     }
-    ulong expectedSize = (data[0] << 24) | (data[1] << 16) |
-                       (data[2] <<  8) | (data[3]      );
+    ulong expectedSize = uint((data[0] << 24) | (data[1] << 16) |
+                              (data[2] <<  8) | (data[3]      ));
     ulong len = qMax(expectedSize, 1ul);
     QScopedPointer<QByteArray::Data, QScopedPointerPodDeleter> d;