On Mon, Feb 11, 2008 at 05:48:54PM +0200, Peter Gibbs wrote: > Looking at just this one case, we see that string_ord is called with a > NULL s argument, whereas the function header states that s is nonnull. > The GCC optimiser believes what it is told, and therefore discards the > test for s being not null, and calls string_length regardless. > string_length has also been told to expect a nonnull argument, and > behaves accordingly. I strongly suspect that most, if not all, the other > failures stem from the same logic. > > There are two apparent solutions: check all notnull arguments before > calling the functions or remove the nonnull attribute where it is not > true.
Or assert() every single one. Which is what Perl 5 does now: http://public.activestate.com/cgi-bin/perlbrowse/p/33291 The "take off and nuke the entire site from orbit" solution. (And, in my opinion, the only way to be confident that function annotations aren't introducing bugs along with the optimisations, (sort of) throwing the anti-baby out with the anti-bathwater. Or whatever the correct opposite of the cliché is) Prior to that patch we'd hit two or three bugs where a newer gcc had started using the not-NULL annotations to make optimisations, introducing bugs. In the process of making that patch I found several wrongly annotated functions, and subsequently a couple more incorrect annotations have been found. Without checking them, I regard them as potential land mines (or time bombs), as perfectly working source code that compiles, makes test everywhere, and is released (and distributed the world over) suddenly could stop working some years in the future when someone compiles it on a compiler with optimisations not available currently. Nicholas Clark
