sri-arpa.189 re: read(fd,&y,sizeof(y))

[ebk at iedl02.UUCP]

> From:  Steve Hartwell <hartwell at Su-Shasta.ARPA>

> I see a degree of cleanness in the basic datatype promotions from small
> ints to "generic" ints, and small floats to "generic" floats (that is,
> doubles) when passed as parameters, and I believe that that specification
> was made with the intention to aid in simplifying compiler implementation

Fine. Actually, it was probably made to avoid the pre-lint (or lazy
programmer) problems of passing parameters to external functions.

> And I see no reason why this concept should not be generalized to
> pointers as well.  Passing a character as an argument to a function
> without an explicit cast is hardly reckless abandon; K&R say that
> chars are members of the int family and are treated that way.  Why should
> passing a pointer be any more stringent?  It seems so much more conceptually
> clean to me to say that a (foo *) is a member of the pointer family and
> give the compiler implementors (and program writers) a break.

It seems really clean to me too, except that this would really give
implementors of C on word addressable machines major problems!
I believe it was pointed out earlier that on a PR1ME, a char pointer
was 48 bits, and a regular pointer 32 (or so).  On a DEC-10,
a pointer to a (36-bit) int can be represented in 18 bits, but
a pointer to anything smaller (a `byte-pointer': bytes are variable
length), such as a (hopefully 18-bit) short, or a (7 or 8 bit, whichever
you want) char, would need to be 36 bits! (Of course you could waste memory,
and make all pointers 36 bits, but you still need completely different
instructions for accessing an int and accessing anything smaller.)
IT IS NECESSARY, FOR PORTABLE CODE, FOR THE COMPILER TO ALWAYS KNOW WHAT TYPE
A POINTER POINTS TO!!

> That is why I think that null pointers should be represented as NULL,
> whose definition is 0 *cast to a pointer to anything you like*; I don't
> believe that it should make a difference whether it is a (char *) 0 or
> a (struct _iob *)0.

Not to be dogmatic, but it is necessary that NULL be a special case.
To not break every program ever written, a C implementation has to consider
(something *)0 to be a null pointer. However, a null pointer cannot always
have the same bit pattern for all types. A null character pointer
on the DEC-10 would still be a byte pointer, and therefore have a '7'
in the length field. (Unless you want to make your compiler ugly and have
a null pointer have a different representation than another pointer of
the same type. Note that this is not the same as having a different
external representaion - what the programmer sees should be a 0, at least
under the defined cases of assignment and comparison.)

> My view is that program control and data management is complex enough
> as it is, and if by clustering basic operative groups {ints, floats, pointers}
> can free me from cast slavery then I would argue for it.  Fervent
> bible-thumping serves no purpose in a discussion which considers the
> merits and limitations of the standard(s); we /know/ what it SAYS;
> but you certainly hold no patent on its interpretation, or on what
> is worth cross-examining.

Saying that the standard is `doubleplusungood' doesn't give much consolation
to whoever has to rewrite almost every program in existence when porting C
to a problem machine. It's not `Bible-thumping' to point to the standard;
it's an attempt to keep programs correct on any machine or C implementation.
However, when K&R was written, I don't think they really believed that C
would exist on as many machines with as many different architectures
as it does now. K|R probably wasn't thinking about the minute attention
given to some of the passages quoted in this newsgroup, or they would
have been more careful about the occasional lapse of precision in
differentiating between 0 and NULL, and the "distinction" between an
integer and an *int* (boldface underline...)

John Owens
...!{duke!decvax}!mcnc!ncsu!uvacs!icase!oducs1!owens_j
weren't written with