Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards,net.lang.c Subject: Re: read(fd,&y,sizeof y) Message-ID: <1815@rlgvax.UUCP> Date: Sun, 18-Mar-84 12:58:32 EST Article-I.D.: rlgvax.1815 Posted: Sun Mar 18 12:58:32 1984 Date-Received: Mon, 19-Mar-84 07:16:51 EST References: <17552@sri-arpa.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 56 > I don't think this is non-portable. For a machine which has pointers of more > than one width, the compiler can be expected to widen the shorter ones to > the width of the largest as it is pushed onto the argument list, just as > chars are promoted to ints when pushed. The called function will know it's > stored that way and shorten it if it needs to before it's used. Anyone who expects a C compiler to do this is going to be sorely disappointed. There is NOTHING in K&R which says that this must be done, and there is no reason for a compiler to do so. It is explicitly stated in K&R that integer and floating point values are coerced to "int" and "double", respectively, so one would expect this to happen. > So it doesn't matter what the type of "y" is in the read call is or what > the actual width of &y is. It seems simple to me that there should be only > one width of a pointer on the argument stack [Not necessarily the width of > an int, either]. WHY? Why should there be only one width of a pointer on the argument stack? Just to make life easier for lazy programmers who refuse to write type-correct code no matter how often they've been told to? The analogy between different widths of "int" and different width of pointer breaks down because there is a semantic difference between "char", "short", "int", and "long" in the C language that pertains directly to the width of the object; the semantic difference between "char *" and "int *" has nothing to do with the *width* of those pointers - any difference or lack of same between their widths is purely a consequence of the C implementation and of the architecture of the underlying machine. > p.s. this also speaks to the NULL vs. 0 vs. ((char *) 0) issue. No, it doesn't. Even if a C compiler took the ill-advised step of "widening" pointers when passed as arguments, this would have no effect on a program which illegally passed an "int" of 0 to a routine expecting a pointer. We've repeatedly heard ideas for changes to the C language or the C compiler to "solve" the "problem" caused by the facts that 1) C has several different pointer types which may not have identical implementations and 2) that null pointers in C are represented by coercing the "int" value 0 to a pointer, and that C has no way of telling the compiler what kinds of arguments a function takes, so the 0 value must be coerced explicitly with a cast when passed to a function. THIS ISN'T A "PROBLEM", FOLKS, AND IT DOESN'T REQUIRE A "SOLUTION". The way to "solve" the "problem" is to write type-correct code and explicitly cast all NULLs or 0s passed as values to routines expecting pointers. This requires NO changes to C, or to any correct C compilers; it merely requires changes to incorrect C code and to the incorrect models of the C language held by certain programmers. And if you have trouble finding all the places you forgot to cast pointers, well, there's a very nice tool - at least on UNIX - to fix this. It's called "lint". USE IT. This non-problem requires no further debate; there is only one correct way to deal with it. Tired of explaining pointers, and tired of pointing people back to K&R, Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy