Patches

[Tomaz Canabrava]

On Mon, May 12, 2014 at 10:13 PM, Dirk Hohndel <dirk at hohndel.org> 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