[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