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? _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
