jdb@s1-c@sri-unix.UUCP (09/23/83)
A while back I posted a message to this group concerning the use of C on a machine with tagged pointers. (In my particular case, the machine is the S-1 Mark IIa.) I received a number of thoughtful replies, but for various reasons only a few of my direct-mail responses made it to their destinations. Several respondents pointed out that C guarantees that no object resides at location zero ("...it is guaranteed that the assignment of the constant 0 to a pointer will produce a null pointer distinguishable from a pointer to any object" -- C Programming Language, p. 192). I was aware of this; it motivated my suggestion that (char *)0 produce a pointer with a "nil" tag. Unfortunately, there are situations where the use of a "true" pointer to zero is desirable; e.g. &((struct xyzzy *)0)->abcde to obtain the offset of "abcde" in a structure of type "xyzzy". It is aesthetically displeasing to treat 0 specially so that ((int *)XYZZY)[i] is an invalid reference through a null pointer if VWXYZ is zero, but is OK if VWXYZ is anything else. (Consider code written in C which patches interrupt vectors in low core.) Other problems which show up are the initialization of the BSS to zero (which MANY programs rely upon to initialize BSS pointers to NULL) and routines such as "execl", for which the last argument in the argument list is defined to be the integer 0. I can't simply #define NULL to the appropriate nil pointer unless I want to type-cast each use or suffer through pointer type conflict messages from "(p)cc" and "lint". We have tenatively decided to change the architecture of the S-1 so that a tag of 0 (formerly an invalid pointer tag) will be treated as a "user-defined" tag. This will allow the use of pointer manipulation instructions (move pointer, validate pointer, etc.) without producing an invalid pointer fault. John Bruner S-1 Project/LLL