the nil pointer is not zero

[Rob Carriere]

In article <171 at nazgul.UUCP> bright at nazgul.UUCP (Walter Bright) writes:
>In article <14516 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>/I don't think so.  What good would it do you to know how a null pointer
>/is represented?  There is nothing useful you can do about that.
>
>1. Explanations of how C works become much simpler (note the endless debate
>   on usenet about NULL and 0). Making C more understandable with fewer
>   counter-intuitive rules is useful.

True, but hardly the only criterion.  I would argue that this is a problem of
education: you don't see mathematicians protesting the extreme overloading of
symbols like 0, 1 or x.  The potential for confusion is much greater (and at
least as serious) there as it is with the nil == 0 situation.  Finding what
the math educators are doing better than the C-educators and changing the way
we teach C accordingly seems a more productive solution.[1]

>2. You will be able to reliably be able to use memset and calloc to initialize
>   structures containing pointers.

Again, true.  But isn't this a sepcification bug, rather than a langauage bug?
I think we need a function that can realiably initialize structures containing
pointers, floats, doubles and long doubles; I don't think we should hack the
language instead.

[1] My guess: (1) C is taught at too low a level of abstraction.  If your
    daily mode of thinking about pointers involves bit-patterns, something is
    wrong.    (2) Insufficient stress on the fact of overloading.  My abstract
    algebra book spends _several_pages_ carefully going through the various
    meanings of the symbol x (a number, an unknown, a polynomial), how they
    interact, why the overloading convention makes sense, and under what
    circumstances you should disambiguate to avoid confusion. 

SR
---