[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