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!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: offsets in structures.
Message-ID: <194@rlgvax.UUCP>
Date: Sat, 13-Oct-84 20:19:37 EDT
Article-I.D.: rlgvax.194
Posted: Sat Oct 13 20:19:37 1984
Date-Received: Mon, 15-Oct-84 01:38:55 EDT
References: <185@rlgvax.UUCP> <1013@bbncca.ARPA>
Organization: CCI Office Systems Group, Reston, VA
Lines: 29

> >That's a broken compiler.  "(struct foo *)0" is of type "pointer to 'struct
> >foo'", so adding 1 to it should make it point to the "next" object of type
> >"struct foo".
> >
> >	 Guy Harris
> >
> 
> As John Bruner has already pointed out, this is not at all broken behavior on
> the part of the compiler.  Section 7.14 of the C Reference Manual (p. 192 in
> K&R) says, " . . . it is guaranteed that assignment of the constant 0 to a
> pointer will produce a null pointer distinguishable from a pointer to any
> object."  This means that although "(struct foo *)0" is indeed of type
> "pointer to 'struct foo'", it is guaranteed not to point to any object, so it
> is meaningless to refer to the "next" object.

Yes, but would you trust any compiler that optimized

	(int) ((struct foo *)0 + 1)

into 1 not to optimize

	(int) ((struct rp11_regs *)177550 + 1)

into 177551?  At best, it may just be optimizing (0 of any kind) + N into N;
it should still check the kind of 0 before it forges ahead with this
optimization.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy