Dirk Hohndel dirk at
Mon May 12 18:13:25 PDT 2014

On Mon, May 12, 2014 at 10:08:08PM -0300, Tomaz Canabrava wrote:
> We can achieve that by throwing an error. but since we didn't hit any
> Q_ASSERT till now on the code I think we are pretty safe. :)
> or if you prefer I can readd the check for nulls.

The Q_ASSERT are only triggered in Debug builds, but all the end user
builds are Release builds, so we wouldn't see them if our users are
hitting them.

That's why there were both Q_ASSERTs and if (d == null) checks. At least I
hope that's why we had both of those. :-)

I think we're fine as is (that's why I pushed the change). I don't see how
we could end up with invalid ids. But fact is that this is bad programming
practice. And I'd like to do an audit of the code and look at all the
places where we COULD get a null pointer back and then dereference it and
create a way to handle all of them in a sane manner without crashing.


More information about the subsurface mailing list