[Development] QtCore missing check for memory allocation

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Wed Feb 25 16:30:56 CET 2015

Il 25/02/2015 13:35, Ulf Hermann ha scritto:
>> I noticed that in qglobal.h Q_CHECK_PTR may be a noop in case
>> QT_NO_DEBUG is set. Q_CHECK_PTR is used to check if memory allocations
>> succeeded (e.g. QVector::reallocateData).
> Until 9d44645eae144fcfefa0de2455d41f04d29c40d4 (September 2014) most of QVector's allocations weren't checked at all and surprisingly no one had complained about that before I did. The common theme is "If you need so much space you better design your own data structure". I find that argument lacking because memory allocation can fail for a number of reasons, not only because you have requested a too large single chunk of memory. Furthermore people keep saying "What can we do if we detect a failed memory allocation? Qt is in an invalid state then and we have to crash anyway." I somewhat agree to that, but we should really crash reliably without writing or reading random user memory before.
> We should thus do Q_CHECK_PTR on every memory allocation in Qt and we should fix Q_CHECK_PTR so that it works under all circumstances.

That's a much bigger commitment than changing QVector, though. All of 
Qt's codebase assumes infinite memory, so that allocations never fail. 
In other words, only a handful of places currently check for such OOM 
conditions, and it's unclear what should happen in case a OOM is 
detected (apart from crashing).

And on the other hand, this assumption of having infinite memory has 
held for a while -- why should now people have a slower library because 
of all those checks?

>> Is QT_NO_DEBUG really disabling the check for valid memory allocation?
> You need QT_NO_EXCEPTIONS and QT_NO_DEBUG for Q_CHECK_PTR to be a qt_noop(). I can't say I like this situation, but the point seems to be that you cannot throw bad_alloc if you've compiled without exceptions. I would argue for just crashing in this case, by accessing a known-bad address. That's quite a behavior change, of course.

Or a simple call to qFatal()...?

Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150225/22889ff9/attachment.bin>

More information about the Development mailing list