Re: CVS commit: src/sys/ufs/lfs

[Ben Harris <bjh21%netbsd.org@localhost>]

In article <441D69CC.6060305%omicron-persei-8.net@localhost> you write:
>Manuel Bouyer wrote:
>
>>Then maybe NULL should be defined to something else than 0 on those
>>platforms ? I wonder how much things will break if we have NULL != 0
>>though ...
>
>my guess is more things would break, just think of all the code that does:
>char * ptr;
>ptr = NULL;
> 
>if (ptr)
>   ...;

Um, that's guaranteed to work even if the representation of a null 
pointer isn't all-bits-zero.  I can't currently remember the full rules, 
though.

>I was merely presenting it as a way to catch derefs of bad pointers at a 
>more convenient time.  If I wrote code with this kind of bug I'd want it 
>to crash sooner and give me a useful backtrace rather than later and 
>possibly a misleading backtrace.

In that case, KASSERT(thing != NULL) is probably what you wanted (along 
with initialisation to NULL, maybe inside #ifdef DIAGNOSTIC).

>Even on ARM the early init to NULL would likely be better given it would 
>at least die on the next page fault as Ben says it would.

It's not always that nice.  I've had all sorts of interesting failures
from vector table corruption.  Now I come to think of it, though, the
arm32 ports write-protect their vector page most of the time, so of the
ARM ports, it's probably only acorn26 that allows kernel writes through
null pointers.

-- 
Ben Harris