On Mon, May 12, 2014 at 10:13 PM, Dirk Hohndel <[email protected]> wrote: > 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.
audit the code is something I think we really should do. I was trying to untangle some of the code and a few stuff I can't understand by it's name what it does, for instance 'get_dc_nickname' seems to set the dc nickname instead of returning it. right now I'm doing what anton asked me, porting the planner code to the new profile, so I think I'll finish this by this week. > /D _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
