Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: To comment 48: Xenix
Message-ID: <17778@sun.uucp>
Date: Fri, 1-May-87 03:24:51 EDT
Article-I.D.: sun.17778
Posted: Fri May  1 03:24:51 1987
Date-Received: Sat, 2-May-87 14:45:36 EDT
References: <77200001@uiucdcsp> <77200008@uiucdcsp>
Sender: news@sun.uucp
Lines: 57

> >	1) a 32-bit zero value *is* an integer; it just doesn't
> >	happen to be an "int";
> 
> True, but irrelevant:
> (integer was used in terms of the latter, that doesn't need explanation).

Oh, yes it does.  The term "integral type" is used both in K&R and in the
ANSI C draft, and does NOT just refer to "int".  0L is an integer in
C, even though it is not (necessarily) an "int".

> If NULL is not (int)zero, then C should not be using the symbol "0"
> to represent it and (int)0.

I agree, given all the confusion overloading the symbol "0" causes,
but it's too late to fix things now.

>       "the assignment of the constant 0 to a pointer will produce a 
>        null pointer".
> 
>        Meaning? the pointer now has the value of zero.
>        (or can this be seen as compiler dependent).

Nope.  The pointer now has the value of a null pointer of the
appropriate type.  On some implementations the pointer in question
may have all its bits zero; on other implementations, it may not.

>        Can each compiler writer have their own way of representing 
>        a NULL pointer (internally).

I presume by "internally" you mean "internally to the generated
code".  (How the compiler works internally is irrelevant; it is a
black box.)  A compiler writer can represent NULL pointers with any
bit pattern they choose, as long as NO pointer to any object will
have that same bit pattern (I include tag bits, etc. here - if you
have tag bits, you may represent a null pointer with the same
non-tag-bits that represent a pointer to an object, as long as the
tag bits are different and as long as this difference will cause a
null pointer not to compare equal to said pointer value).

>        We have two different types (pointers and integers)

We have a lot more types than that.  We have several different
integer types, two floating-point types (three in ANSI C), a
theoretically infinite set of structure types, a theoretically
infinite set of union types, a theoretically infinite set of
enumerated data types (yes, I know they are considered "funny"
integral types in ANSI C), and as many types of pointers, arrays, and
functions as we have data types plus "pointer to void" and "function
returning "void" (the set of function types is "bigger" in ANSI C in
that a function's type includes the types of its arguments).

(The astute reader will note that this implies that the cardinality
of the set of data types is infinite; in theory, it sure is.  In
practice, compilers will probably impose a limit on how many levels
of pointer indirection they will support, as well as limits on how
many different structure, union, and enumerated types they will
support.)