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.