Source-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/ufs/lfs
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
Home |
Main Index |
Thread Index |
Old Index