summaryrefslogtreecommitdiffstats
path: root/src/corelib/io
diff options
context:
space:
mode:
authorThiago Macieira <thiago.macieira@intel.com>2015-09-27 11:52:35 -0700
committerThiago Macieira <thiago.macieira@intel.com>2015-09-28 16:29:50 +0000
commit84a806589f93240ef39696729c6ce4c10bc4ab02 (patch)
tree2cce467053f6f9aa000ccb87af0923e302d01412 /src/corelib/io
parentb03d91e3f7d9b3ff96692d4e284b003ca5b90b82 (diff)
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>
Diffstat (limited to 'src/corelib/io')
0 files changed, 0 insertions, 0 deletions