[Development] QtCore missing check for memory allocation

Oswald Buddenhagen oswald.buddenhagen at theqtcompany.com
Wed Feb 25 20:07:58 CET 2015

On Wed, Feb 25, 2015 at 08:01:54AM -0800, Thiago Macieira wrote:
> On Wednesday 25 February 2015 16:48:44 Ulf Hermann wrote:
> > >> 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.
> > > 
> > > I disagree on both accounts.
> > 
> > Could you elaborate a bit?
> I disagree that we should do Q_CHECK_PTR after every memory allocation and I 
> disagree that Q_CHECK_PTR should do something in all circumstances.
elaborate, not restate more verbosely.

> > That "every memory allocation" may be relaxed a bit as there might be places
> > where the code can deal with 0 or where we pass the pointer straight on to
> > user code and can expect the user to check it. The default should be
> > checking for 0, though.
> I really disagree. If we wanted to find bad memory allocations, we should turn 
> exceptions back on and write exception-safe code. Anything else is putting the 
> burden on the common code path.
as ulf pointed out, a rather trivial wrapper which ensures deterministic
behavior is hardly a burden.

> > > That's undefined behaviour. If you write code:
> > > 	if (!p)
> > > 	
> > > 		*(char*)p = 42;		// crash
> > 
> > I'm not saying we should access p in this case, but rather some fixed place
> > of which we know we cannot access it, to *reliably* raise a segfault. Maybe
> > there is even a more elegant way to trigger a segfault than accessing
> > invalid memory.
> The only reliable way of causing a segfault is raise(SIGSEGV). You can't 
> reliably trigger a memory problem because, by the very definition of it, the 
> compiler is allowed to assume it doesn't happen.
you can assign to a volatile pointer and deref it. the compiler is not
allowed to optimize that away. we established that much last time we
discussed this topic.

> > [...] Q_CHECK_PTR should mean "If the pointer is 0 either throw an
> > exception or abort right away. Don't just continue."
> I understand your arguments, but I still disagree we should act.
well, and i say you are wrong.
see the problem with this kind of argumentation?

More information about the Development mailing list