>> 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? 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. > 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 point is this: With the current behavior you're not actually guaranteed to get a segfault. The client code might not access *p, but rather p[<some large number>], and that might hit valid memory. Or it might store p, do whatever funny arithmetic on it with the assumption that it's not 0, and run into some other incorrect behavior. An attacker could specifically search for such a case and overwrite some important piece of information like this. We don't want that. Q_CHECK_PTR should mean "If the pointer is 0 either throw an exception or abort right away. Don't just continue." Ulf _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
