Ticket #105 (NULL checks)

[Mark Glines]

Nicholas Clark wrote:
> Until gcc fixes that (has it?), nonnull can't be relied on to be truthful.

As of gcc 4.3.2, it hasn't.

We now have asserts for all the functions tracked by headerizer, which 
is a good portion of the Parrot codebase.  That exposed 15 cases where 
function arguments had been mistagged as nonnull.  Other than one or two 
cases of sequencing bugs or other weirdness, the majority were all 
obvious cases where the function was prepared to handle null pointers 
but the prototype was wrong.

Here's the list of arguments I added _NULLOK to:
src/atomic/gcc_x86.c: parrot_i386_cmpxchg()'s "expect" and "update", r34866
src/list.c: list_set()'s "item", r34772
src/list.c: list_push()'s "item", r34772
src/list.c: list_assign()'s "item", r34772
src/inter_call.c: set_context_sig_return()'s "ret_x", r34731
src/inter_call.c: parrot_pass_args()'s "src_indexes" and "dest_indexes", 
r34731
compilers/imcc/pcc.c: insert_tail_call()'s "meth", r34726
src/string.c: string_make_direct()'s "charset", r34712
src/pmc_freeze.c: do_thaw()'s "pmc", r34712
src/pmc_freeze.c: visit_todo_list()'s "pmc", r34712
src/pmc_freeze.c: visit_todo_list_thaw()'s "pmc", r34712
compilers/imcc/main.c: imcc_run_pbc()'s "output_file", r34525
compilers/imcc/main.c: compile_to_bytecode()'s "output_file", r34525

If gcc were doing its job, the asserts wouldn't have caught any of those 
cases.  It seems like gcc's "contract enforcement" seems to consist of a 
compile-time check with a warning, and no runtime followup.

Mark