On Monday, 6 February 2023 11:37:07 PST Thiago Macieira wrote: > On Monday, 6 February 2023 11:21:13 PST Lisandro Damián Nicanor Pérez Meyer > > wrote: > > When building qtbase 6.4.2 on Debian I see: > > > > In member function ‘__ct ’, > > > > inlined from ‘detached’ at > > > > ./obj-x86_64-linux-gnu/include/QtCore/../../../src/corelib/tools/qhash.h:5 > > 7 > > 5:20, inlined from ‘detach’ at > > ./obj-x86_64-linux-gnu/include/QtCore/../../../src/corelib/tools/qhash.h:1 > > 5 > > 01:75: > > ./obj-x86_64-linux-gnu/include/QtCore/../../../src/corelib/tools/qhash.h:5 > > 5 > > 9:17: warning: argument 1 value ‘18446744073709551615’ exceeds maximum > > object size 9223372036854775807 [-Walloc-size-larger-than=] > > /usr/include/c++/12/new: In member function ‘detach’: > > /usr/include/c++/12/new:128:26: note: in a call to allocation function > > ‘operator new []’ declared here 128 | _GLIBCXX_NODISCARD void* operator > > new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) > > > > Is this something to be worried about? > > No. It's a false positive. The value that GCC is reporting is also > impossible: > > size_t nSpans = numBuckets >> SpanConstants::SpanShift; > spans = new Span[nSpans]; > > numBuckets is a size_t, so shifting it right will shift 7 (SpanShift) zeroes > in. That means the maximum value that nSpans could assume is 2^(64-7) - 1. > > If you multiply that value by sizeof(Span) == 144, that would overflow the > size_t though.
Actually, maxNumBuckets is wrong, allowing bucketsForCapacity to overflow. But in practice this will only affect you after the QHash has grown to more than half the virtual memory size (which can only happen on 32-bit systems today). Working on a fix right now. Will push soon. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
