lint, pointers, 0 (what else?)
Guy Harris
guy at rlgvax.UUCP
Sun Feb 10 05:37:30 AEST 1985
> 'C' *is* ruined in that way that the kind of integer that can hold a
> pointer is not pre-defined.
I agree 100%. That's the disadvantage of a language that "jes' growed",
like C (the advantage is that you aren't stuck with incorrect decisions
made when the language was cast in concrete). The fact that it does
quite well, even given its limitations, is a testimonial to the parts
of C that they got right (C here referring to all post-V6 C's; the C
that came with V6 was inadequate, given the lack of "unsigned" and "long"/
"short" modifiers, etc.).
> > > The way K&R intended (and partially documented it).
> >
> > It isn't clear that they ever intended it to work this way.
>
> Ok, I don't know whether K&R *intended* to work '0' as the nil pointer
> on function call. Looking at 'stdio' and at V7 UN*X programs I just
> can't help getting that impression, though.
K&R didn't write most of that code, and what they did write may have come
before they thought about the nil pointer question. Heck, they changed
their minds when confronted with new data - "-=" disappeared when it was
realized that "a=-b" was ambiguous (and now "=-" is gone from the language).
Lots of UNIX code has gotten cleaner (at least with respect to type-correctness)
as time has gone on - as of 4.2BSD and System V, the code is lots better.
(A lot of System V looks as if somebody at least tried to "lint" most of the
commands.)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
More information about the Comp.lang.c
mailing list