🚀 go-pugleaf

In article <43cgmb$cec@news0.rain.rg.net>, Paul Long <plong@perf.com> writes
: ....
: These constraints would render the following non-conforming.
: 
:     void foo(struct S { int a; }, struct S *, int i, int a[sizeof i]);
: 
: Is function-prototype scope provided for completeness? Would it have been more
: confusing to preclude it? What gives?

The answer that I quite a while ago got is the problem with pointers.  C
was developd on computers that had but one pointer-form.  On such machines
it would be enough to (forward-)declare that a parameter is a pointer to
sumthing, and that is enough for the argument-passing code.  The compiler can
afford to wait until later, when reallie needed, for to see the hoal type.

Consider the variable
	struct S
	{	char k[10];
	} h;
.  Is the code for referring to it the same as for the variable
	char h[10];
?  On the PDP-10 I guess that it would be the same, and both yield access
through byte-pointer.  It is quite different from that which accesses the
variable declared by 'int' instead of 'char'.

That is, in the parameter-type 'struct S *' there is not enough
pointer-typing information for the compiler to generate the right
argument-passing code.

I consider this restriction a mistake, and that the best cours was to
assume, if to the implementation it matters, that a not known pointer
points to a type with the most restrictiv alignment--for example, on a
PDP-10 it points to a word and not byte or halfword.