lint, pointers, 0 (what else?)
Ron Natalie <ron>
ron at brl-tgr.ARPA
Thu Feb 7 07:26:10 AEST 1985
> Finally, there is no good reason for not having
> sizeof(int)==sizeof(char *). 'int' is not guaranteed to be the fastest
> integer type around (speedof(int)<=speedof(short) on practically all
> machines...). And if you are worried about getting an efficient integer
> type portably, why don't you just use 'typedef short EfficientInt;' :-?
> K&R (quoting from my mind) calls 'int' the 'natural' choice for an
> integer data type on the target machine. In my opinion, the 'natural
> choice' is the size of a pointer (the largest pointer that is).
Yes there is! There is no good reason for you to be too lazy to allow it.
C is a systems programming language. I balk at having it bastardized into
an unusable higher level language. You can not make an assumption about
the sizes. The implementation of the compiler types should be the best
for the operation of that system. If you care not to write code that is
portable to those machines, thats your affair, but I can't justifying adding
an artificial restriction on the language just to make you happy.
Quoting K&R from the book: "Plain" integers have the natural size suggested
by the host machine architecture. This means WORD size on most machines,
since that is arithmatically the basic element. Newer machines with
larger word sizes may have smaller pointer sizes, older machines with
smaller word sizes required larger pointers.
STOP RUINING C FOR SYSTEMS PROGRAMMING.
> [null pointer]
>
> I don't care whether the null pointer spells out Mona Lisa in EBCDIC,
> as long as I can compare it to '0', assign it as '0', and (sorry, I
> like it) pass it as '0' where a pointer should go -- without casting,
The new C standard allows you to do this. But what do you want the
compiler to do now, be clairvoyant? How is it supposed to tell that
0 is indeed a pointer, rather than the plain integer constant when
passed to a function, so that it can change the size (or in your case)
map it to MONALISA in EBCDIC.
> The way K&R intended (and partially documented it).
It isn't clear that they ever intended it to work this way.
> While we are on the
> subject, what about the same treatment for '-1', the (de facto) standard
> error return value?
>
Why not say that all integers are mappable to pointers, hey lets do away
with types at all!
More information about the Comp.lang.c
mailing list