Ticket #105 (NULL checks)

[Mark Glines]

Andy Dougherty wrote:
> On Wed, 31 Dec 2008, chromatic wrote:
> 
>> On Wednesday 31 December 2008 12:26:07 Andy Dougherty wrote:
>>
>>> This is not a hypothetical what-if situation.  I have lost many hours to
>>> just this situation.  See my long example in ticket RT #50684.  To save
>>> everyone from looking it up, I will extract the relevant example here:
>> Your copy and paste accidentally omitted the part where you enabled 
>> optimizations and disabled debugging assistance, which, as you might expect, 
>> made debugging more difficult.  I've had similar problems when I added asserts 
>> and wondered why they weren't working.  I'm not sure that's a problem we can 
>> solve.
> 
> The issue I was chasing only showed up under optimization.  That's why I 
> was enabling optimization.
> 
> And yes, it is a problem we can easily solve.  We can solve it by getting 
> rid of the attribute_nonnull decorations and replacing them with 
> assert()s.

We had a talk about that in the IRC channel today, where I was 
advocating the same thing.  I got some good feedback from Andy Lester 
and chromatic.  The sense of the room was that the attribute provides a 
compile-time check for obvious NULL passings (some warnings are issued 
when this case is detected), and they didn't want to throw out that 
seatbelt just yet.

I think the idea is that the asserts will crash unoptimized builds, so 
we can use that to fix things up to work cleanly in optimized builds 
too.  I didn't get a clear answer about tracking down NULL pointer bugs 
that only occur in optimized builds, but I suppose we can make a local 
patch to disable attribute_nonnull in that case if necessary.

Mark