"expandable" structs with last element declared using [1]

[Sean Fagan]

In article <468 at bbxsda.UUCP> scott at bbxsda.UUCP (Scott Amspoker) writes:
>In article <477 at 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 at sco.COM    |    -- Thomas Magnum (Tom Selleck), _Magnum, P.I._
(408) 458-1422   | Any opinions expressed are my own, not my employers'.