Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: offsets in structures. Message-ID: <4517@utzoo.UUCP> Date: Mon, 22-Oct-84 15:58:55 EDT Article-I.D.: utzoo.4517 Posted: Mon Oct 22 15:58:55 1984 Date-Received: Mon, 22-Oct-84 15:58:55 EDT References: <393@orion.UUCP> <5172@brl-tgr.ARPA>, <6542@mordor.UUCP>, <5400@brl-tgr.ARPA> Organization: U of Toronto Zoology Lines: 53 > Although I see no particular use for the following piece of code, > I believe that it is supposed to be legal both now and in the ANSI > standard: > > char *foo; > > foo -= (long)foo; /* or (int) perhaps */ > /* foo now is NULL */ This falls down if pointers are not byte indexes, e.g. if the byte info is up in some of the high-order bits. (I think the pdp10 does that.) Remember that the ptr--->long conversion is not required to produce a sensible number. There is also a more subtle assumption here, that memory is in fact organized as an array of bytes, so subtracting the "position" of a byte pointer from the pointer gives 0. (I can't immediately think of a counterexample, but it's not ruled out.) Finally, nowhere does the ANSI standard (or K&R) say that *any* computed pointer value, regardless of the computation, must compare equal to integer constant 0 (i.e. NULL). The only way to get a pointer that is guaranteed to compare equal to NULL is to derive it from an explicit NULL. > char *malloc(), *where; > > where = malloc( (unsigned)40 ); > > subr( where ); /* check validity of `where' and does something */ > > Here a NULL pointer must be type-compatible with other pointers. Using > a special "nil" pointer could easily get in the way here (subr() might > end up with special-case "nil"-handling in-line code every time its > parameter is used). Why? If subr() compares the pointer to an explicit NULL, then that comparison is done against the special "nil" value. If the comparison is against a pointer derived from an explicit NULL, same thing. If the comparison is against anything else, there are no promises made by the ANSI draft or K&R. The choice of bit pattern to represent NULL is entirely irrelevant. > What more does using special "nil" get you than using a 0, apart from > hardware check against dereferencing NULL? In any case, the hardware > check is unnecessary if you write your code correctly. Are we all > hackers or are there some professional programmers out there? Among other things, on some "smart" pieces of hardware, you cannot even load some bit patterns into a "pointer" register without getting a trap. On such hardware, you can't use such a bit pattern to represent NULL without all kinds of hassles when manipulating might-be-NULL pointers. On at least one such machine that I've heard of, all-zeros is one of the bad bit patterns. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry