Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!linus!philabs!cmcl2!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.lang.c Subject: Re: SIZEOF Message-ID: <443@rlgvax.UUCP> Date: Fri, 8-Feb-85 18:29:03 EST Article-I.D.: rlgvax.443 Posted: Fri Feb 8 18:29:03 1985 Date-Received: Tue, 12-Feb-85 06:48:17 EST References: <347@ecr.UUCP> <393@rlgvax.UUCP> <808@sjuvax.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 42 > It occurs to me that the length of a pointer simply being required to > be constant (even within the same data type) presents problems. Many > microprocessors now implement span-dependent addressing, and if your > implementation allows passing of an array wholesale, and that array is > small, there is no reason why one shouldn't be able to optimize the pointer > size as being relative to some register variable which points to the > current function's bottom of passed data. > > Is this a problem in practice - are pointers in fact obliged to be the > same size everywhere, or am I missing something? No, you are not missing anything - there is only one representation of a "foo *" in a C program. In the example you give, the called routine would have to know that the pointer was relative to that particular register (or, if the pointer indicated that fact, would at least have to know that the pointer in question was a relative pointer). This means that you'd either have to introduce a character replacing "*" to indicate this new flavor of pointer, or introduce a pragma which said "you can use a relative pointer here". (Which microprocessor are you referring to?) > Since compilers need to do type checking anyway, passing 0 instead of NULL > should always be valid. The only problem is that C compilers do *not* do type checking in function calls, because there's no way in the current C language to say that a particular function's third argument is a "char *". As such, passing 0 instead of NULL is not valid (well, passing 0 is the same as passing NULL, and both are invalid; passing (char *)NULL is valid). > Note that K&R says that assigning 0 to an integer generates the appropriate > NULL pointer. This type conversion (it is implied) is automagic, and thus > there *is* a generic NULL, which is the integer 0. No, there is no "generic NULL", there are several "appropriate NULL"s. The integer 0 just happens to be a way of telling the compiler to generate whatever null pointer is appropriate for the pointer type that appears in the expression. Maybe if the word "nil" had been a reserved word in C, and C used "nil" instead of "0" for this purpose, a lot of the confusion that null pointers cause might never have happened. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy