Path: utzoo!attcan!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.std.c
Subject: Re: "expandable" structs with last element declared using [1]
Message-ID: <4171@scolex.sco.COM>
Date: 19 Dec 89 09:55:32 GMT
References: <UZTerlu00VcJEDulRd@andrew.cmu.edu> <463@cpsolv.UUCP> <477@longway.TIC.COM> <468@bbxsda.UUCP>
Reply-To: seanf@sco.COM (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Lines: 40

In article <468@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>In article <477@longway.TIC.COM> uunet!sq!msb (Mark Brader) writes:
>I believe Doug has
>>stated that there are implementations where it doesn't work, but hasn't
>>named any.  Can someone do so (in comp.lang.c)?
>
>Maybe someone thinks that structure fields need not be allocated in
>any particular order.  I wouldn't be surprised if it didn't work on
>some system somewhere, but such a system is probably at fault.

*sigh*  Think:  you have a structure that looks like

	struct foo {
		int size;
		char name[1];
	};

Now, if you're doing symbolic debugging, the information gets encoded as
something like:

	structure <name: foo> <elements: 2>
		integer <name: size>
		array <name: name> <size: 1>
			char

or somesuch.  Now, imagine an architecture that does that in hardware (well,
microcode, probably).  Guess what, there *are* machines that do!  Most LISP
machines do something similar, and there are other machines that can do it
(I'm sure a Burroughs machine can, since they can do everything else 8-)).
Turning on bounds-checking in your compiler, if it supported it, would cause
it to fail.

So, nope, the implementation is *not* at fault.  There are some good reasons
for not making it valid (although I believe they can all be gotten around
somehow), and not only having to do with interpreters.

-- 
Sean Eric Fagan  | "Time has little to do with infinity and jelly donuts."
seanf@sco.COM    |    -- Thomas Magnum (Tom Selleck), _Magnum, P.I._
(408) 458-1422   | Any opinions expressed are my own, not my employers'.