Ticket #105 (NULL checks)

[Nicholas Clark]

One trap: If the gcc attribute_nonnull is still used for these same
functions, gcc can optimize away the NULL checks, rendering them

useless.

I'd recommend also getting rid of the attribute_nonnull gcc

checking. I

have posted about this at length in previous RT tickets, if you

need more

background.

Ok, I've gone and read through RT #49316 and RT #50684. It sounds an
awful lot like attribute_nonnull is an optimization, not a constraint as
I had originally thought. Therefore it's working against us, not
with us.
I'm pretty sure assert() is a C library function.
I think it's a C #define'd macro, not a function, which is not expanded
if you set the right debug #define
(don't know details by heart).

Hmm, you're right. gcc will short-circuit those too, so we'd better get
rid of attribute_nonnull (for now).

If you build without the optimiser (currently the default for parrot, I think)
then gcc doesn't short circuit the assertions, so they fire off if they are
violated, keeping the attribute_nonnulls honest.

Then if you build with the optimiser, and the right macro to stop assertions
being expanded at all (-DNDEBUG, IIRC), it's as if the assertions aren't there,
and gcc may well take advantage of the (honest, validated) attribute_nonnulls
to optimiser better.

Well, it all works as long as the test coverage is good enough.

We've not had any further problems with them in Perl 5 since I added assertions
and fixed all the errors they found.

Nicholas Clark

[Chromatic]

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

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.

-- c

[Andy Dougherty]

Post by Chromatic

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

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.

[Andy Lester]

Post by Andy Dougherty
We can solve it by getting
rid of the attribute_nonnull decorations and replacing them with
assert()s.

An even better solution is to keep the attribute_nonnull and also add
asserts.

The ARGIN()/ARGOUT() decorators are useful both to GCC and to splint,
and who knows what other compiler that might come along. They also
help document the expected API.

xoxo,
Andy

--
Andy Lester => ***@petdance.com => www.petdance.com => AIM:petdance