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