🚀 go-pugleaf

In article <43er80$458@caip.rutgers.edu>, halasz@caip.rutgers.edu writes:
>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.

Is it me, or does this response not appear to even come *close* to answering
the given question?

First of all, old K&R C syntax, with no prototypes whatsoever, was enough for
compilers to generate correct code, presuming the programmer passed the
expected type. Prototypes enabled the compiler to do some consistency checking
and implicit conversions, not solve any inherent inability to generate correct
code. 

Secondly, even if prototypes in general were necessary for correct code
generation, and even if all struct pointers didn't "smell alike", it still
doesn't explain why function-prototype scope is needed. Even if it were
necessary that pointer-type parameters be pointers to complete types, it is
still possible (in fact, it's pretty much mandatory if you want to actually
*use* the function) to declare the complete structure type before the
prototype.

I suspect that function-prototype scope exists so that prototypes can include
the parameter-name identifiers (for purposes of self-documentation) without
corrupting the file- or block-scope namespace in which the prototype
occurred. I also suspect that adding rules to disallow only certain
declarations (i.e. struct declarations) in only certain scopes (i.e.
function-prototype scope) just complicated the rules more than it was worth.




--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com