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

[Tyler Retzlaff <rtr%omicron-persei-8.net@localhost>]

Manuel Bouyer wrote:

> On Sun, Mar 19, 2006 at 12:58:35PM +0000, Ben Harris wrote:
>  
>
> > In article <441D4EFD.1010507%omicron-persei-8.net@localhost> you write:
> >    
> >
> > > YAMAMOTO Takashi wrote:
> > >      
> > >
> > > > what i don't understand here is, why you think NULL initialization is
> > > > better wrt future bugs.
> > > >
> > > >
> > > >        
> > > Would a dereference of the NULL ptr not cause immediate failure?
> > >      
> > Not necessarily.  On older ARM systems, the kernel has a page mapped at 
> > address zero containing the CPU vectors.  Reading through null pointers 
> > works fine, and writing corrupts the vector table, which you'll only 
> > find out about when you next take a page fault, interrupt or whatever.
> >    
>
> 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)
   ...;

Of course good practice is to compare against NULL (as is documented in 
misc/style).

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.

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.

Anyway, at this point I guess I just shouldn't have made the change.