🚀 go-pugleaf

> Unfortunately, you don't have to take the address of a given variable
> to use it, you merely have to take the address of a variable near it
> and add an offset to it.  The way C is defined, this is quite legal.

Even if it is legal (which I doubt), it's not necessarily the right thing to
do.  As such, I consider it perfectly legal for an optimizing compiler to
pretend that sort of thing doesn't happen; if you use disgusting tricks like
that, turn the optimizer off.

> For example, suppose I have a function f, declared as follows:
> 	f(p)
> 		struct { int a, b, c; } *p;
> And I call it as follows:
> 	b()
> 	{
> 		int a, b, c;
> 
> 		f( &a );
> 	}
> According to our venerable friends kerningham&ritchie, this is legal;
> it is also used to some great extent in the older (v6 & v7) unix kernels.

Oh, really?  Could you tell me where in K&R they claim that a C
implementation must:

	1) put "b" and "c" in memory at all in this case?

	2) if it does put them in memory, put "a", "b", and "c" in memory
	   in the exact same fashion that the members of the structure in
	   question are put in memory?

In fact, because of a historical accident, that one *doesn't* work in our
implementation; "int" structure members are put on 16-bit boundaries, but
"int" arutomatic variables are put on 32-bit boundaries.  (Our compiler is
derived from the MIT 68000 compiler, which put 32-bit "int"s on 16-bit
boundaries because that's all it had to do; we later modified it to put
"int" automatic variables on 32-bit boundaries for efficiency on the 68020,
but didn't change the alignment rules for structure members for reasons of
binary compatibility).