On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development < [email protected]> wrote:
> Oh, a nullptr deref is pretty clear in a backtrace. Indeed, but my point is that it's relatively useless for the user (or for the developer for that matter). As you pointed out the dev sees the nullptr dereferencing instantly, the user just gets a crash. The assert is just superfluous is what I'm saying. > Even in a release > build, if you installed the debug symbol package that does with the > distribution's version of Qt. > Humor me, will you? [1] > Please, you debug against a release build, and complain that you don't > get debug checks? > To take your previous example. QPen pen1 = ~~~; QPen pen2 = std::move(pen1); // ... Some code pen1.color(); // Ooops You're missing out on 4000 other checks that way, too! > Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If not, I get segfault. And as it happens I have enough builds, so even if that happens and I can't switch kits and step into Qt, not every one user does have that at their fingertips, however. Having documentation that spells such behaviour clearly, would be satisfactory to me, that's why I was inquiring on *how* the problem, which is a real one, can be mitigated. > That said, I'm pretty sure that a static analyzer can find uses of > objects in partially-formed state with local analysis. > QPen pen; QColor color = pen.color(); If the analyzer can see the above as dangerous, i.e. touching an object with an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied. [1]: https://packages.debian.org/search?suite=testing§ion=all&arch=any&searchon=names&keywords=libqt5core
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
