On Wed, Dec 31, 2008 at 09:22:01AM -0800, Mark Glines wrote: > kjstol wrote: > > > > > > On Wed, Dec 31, 2008 at 5:03 PM, Mark Glines <m...@glines.org > > <mailto:m...@glines.org>> wrote: > > > > Andy Dougherty wrote: > > > 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
