[PATCH] include/platform.h: Define KERNEL_VERSION unconditionally

Rob Landley rob at landley.net
Wed Jun 7 04:10:45 UTC 2006


On Tuesday 06 June 2006 4:56 pm, Shaun Jackman wrote:
> I was only being troubled by network/interface.c. If that check can go
> away, then I have no further complaints.

Should be able to.  Checking the netbsd version of that command for comparison 
purposes might be informative...

> On 6/6/06, Rob Landley <rob at landley.net> wrote:
> > On Thursday 01 June 2006 11:48 am, Shaun Jackman wrote:
> > > [1] 2. Thou shalt not follow the NULL pointer, for chaos and madness
> > > await thee at its end.
>
> I should have mentioned that I was quoting `The Ten Commandments for C
> Programmers (Annotated Edition)' by Henry Spencer. These are not my
> words. Sorry for the confusion.

Oh I've heard it before, although it was several few years ago.  And when he 
was trying to wean people off the "all the world's a VAX" mentality, it made 
a certain amount of sense to question everything.  But NULL is 0, and by 
_relying_ on that we can make busybox smaller.  (0 is false, the null pointer 
is false.  This is good to know.)

> > And on linux and any other sane unix-like system going back to the 1970's
> > we have an inaccessible page mapped there and any attempt to read from it
> > or write to it gives a clean segfault.
>
> On an embedded system without an MMU or even an MPU, this desirable
> feature is sadly not an option. Considering uClinux is only a
> configuration of Linux these days, your statement is false.

I'm aware that on a nommu system you don't get a segfault for anything.  (I 
programmed under DOS for years, they put the _interrupt_table_ down there.)  
But these days anybody who tries to debug software on a nommu system _first_ 
had better know they're playing with fire...

> > > A null pointer doth not point to a 0 of any type,
> >
> > Yes, it does.  And we check for this all over the place.
> >
> >   if(!thing || !*thing) blah.
> >
> > Any system that doesn't understand that is too stupid to live, and will
> > NEVER be supported.  Period.  Full stop.
>
> It's not saying that a NULL pointer is not 0, this is in fact defined
> by the C standard. It's saying that dereferensing the NULL pointer
> does not necessarily give another NULL pointer.

I mentioned a moment ago that dereferencing the NULL pointer usually gives a 
segfault, right?

> There used to be 
> systems that depended on assert(*NULL == NULL)

They're nuts.  We don't.

> , allowing your above 
> test to be reduced to simply if(!*thing), which used to be a common
> idiom for if(thing == NULL || *thing == NULL).

Again, we don't.  I'm fairly certain BusyBox doesn't contain significant 
amounts of code ported directly from 1970's minicomputers.  I'd probably have 
noticed by now.

> > > despite some blasphemous old code which impiously assumes this.
> >
> > You are, quite simply, wrong.
>
> ... unless you've misunderstood the original statement. Although, I
> suppose all rebuttals have to start with the basic assumption that the
> opposition has understood the proposition's argument.

*shrug*.  I'm a computer historian, which means I've at least read about 
systems where NULL wasn't 0, where char was 12 bits long, where identifiers 
were 6 characters at most and this was used as a form of commenting...  I 
assumed you were advocating a change from current policy rather than 
restating the obvious.  Dereferencing a NULL pointer is bad, sure, and on 
Linux systems with an MMU, you get a segfault if you do this, so we're 
unlikely to accidentally do it for long even by accident.

> Cheers,
> Shaun

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list