On 2019-05-20 22:58, Konstantin Shegunov wrote:
[...]
I agree as well, although I have a minor nitpick. Q_ASSERT works only
if it was not stripped while building Qt. Meaning that I'm often
working, as I'm sure other users, on Linux especially, with the
default (i.e. release) version of Qt from the repo. Granted it may be
my own fault, but in this case the assert isn't tripped and this code
simply segfaults for reasons that aren't so obvious.
Oh, a nullptr deref is pretty clear in a backtrace. Even in a release
build, if you installed the debug symbol package that does with the
distribution's version of Qt.
Any suggestions
how to mitigate that? Somehow *suggest* to the user that [s]he's
supposed to build in debug mode otherwise they're on their own?
Please, you debug against a release build, and complain that you don't
get debug checks?
marc:~/Qt/qt5/qtbase$ git grep -we Q_ASSERT -- src | grep .cpp: | wc -l
3907
You're missing out on 4000 other checks that way, too!
And I'm pretty sure that there's a way to keep the Q_ASSERTs in release
mode.
That said, I'm pretty sure that a static analyzer can find uses of
objects in partially-formed state with local analysis. Proof:
const char *p;
~~~~ complicated code ~~~~~
char ch = *p; // WARNING: p might be used uninitialized in this
function
I guess what's missing is a way to tag processes in which
partially-formed states are created for the compiler.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
