Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!ron
From: ron@brl-tgr.ARPA (Ron Natalie )
Newsgroups: net.lang.c
Subject: Re: offsets in structures.
Message-ID: <5385@brl-tgr.ARPA>
Date: Thu, 18-Oct-84 21:06:00 EDT
Article-I.D.: brl-tgr.5385
Posted: Thu Oct 18 21:06:00 1984
Date-Received: Sat, 20-Oct-84 06:57:34 EDT
References: <63@ism780b.UUCP>
Organization: Ballistic Research Lab
Lines: 32

> >A problem with expressions like
> >
> >        &((foo *)0)->bar
> > ...
> 
> Perhaps more robust would be  ((char *)&((foo *)0)->bar - (char *)(foo *)0)
> 
> so that, regardless of the value of ((foo *)0), all that is expected of the
> compiler is that &((foo *)0)->bar be produced by adding the offset to bar
> to the value of ((foo *)0).  There is still the presumption that any pointer
> can be converted to (char *) without loss of information.

But nowhere does the spec say that saying 0->anything or *(pointer_cast)0
is guaranteed to valid at all.  Zero can be put into a pointer so that it
can be checked for later, period.  On certain architectures (like ones that
have different pointer layouts for various types) trying to 0-> something
may not be valid.  Consider the HEP:  The pointers work as follows:

      Char    SHORT   Medium  int (and long)
	0	1	2	0
	1
	2	3
	3
	4	5	6
	5
	6	7
	7
	8			8

In these cases something that begins with short or medium would have
a zero pointer of 1 or 2 even though the compiler traps the special
NULL (0) case and handles it.