Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!mit-eddie!uw-beaver!Teknowledge.COM!polya!Gang-of-Four!dkeisen From: dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) Newsgroups: comp.std.c Subject: Re: "expandable" structs with last element declared using [1] Message-ID: <13015@polya.Stanford.EDU> Date: 28 Dec 89 16:57:05 GMT References: <463@cpsolv.UUCP> <477@longway.TIC.COM> <468@bbxsda.UUCP> <4379@cuuxb.ATT.COM> <15509@haddock.ima.isc.com> Sender: news@polya.Stanford.EDU Distribution: comp.std.c Organization: Sequoia Peripherals Lines: 25 In article <15509@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: Six pieces of code starting from the obviously legal to the questionable. I can't say whether or not it is legal, but if it isn't the problem is the jump from [3] to [4]. All [0] to [1] relies on is the alignment of storage returned by malloc. All [1] to [2] does is add to cp an integer that keeps it within the space allocated by the malloc. [2] to [3] is OK because the address of foo->baz[0] is (by definition)) offset (T, baz[0]) bytes away from foo. But [3] to [4] takes the address of a "nonexistent" element, foo->baz[1]]. If this is legal, then that immediately answers the question as to whether or not structs are "extendible". And [4] to [5] is just the definition of the address of and pointer too operators. -- Dave Eisen Home:(415) 324-9366 / (415) 323-9757 814 University Avenue Office: (415) 967-5644 Palo Alto, CA 94301 dkeisen@Gang-of-Four.Stanford.EDU