🚀 go-pugleaf

In article <43nnt2$ksp@caip.rutgers.edu>, halasz@caip.rutgers.edu writes:
>In article <43mnv1$nkg@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes
>> Could you be more specific? Which of my above statements do you disagree with
>> and why?
>Why function-prototype scope is needed: the pointer-problem is enough
>for to explain it.

The "pointer-problem", as you call it, is not a problem at all.

>
>=the pointer-form is the problem.  Prototype-scope prevents the
>=parameter here
>=	int k(struct S *)
>=from being fullie declared. 

First, the parameter (pointer to incomplete struct type) *IS* fully declared.
What you mean is that it prevents the struct type from being completed. This
is not relevant because pointers to incomplete types (such as the parameter
above) are not incomplete types themselves. They are *complete* types.

Second, assuming you mean that prototype-scope prevents the struct S from
being completed, this fact, along with your statement that prototype scope
solves the "pointer-problem", seems to indicate that *allowing* this struct
type to be completed is what you consider to be the problem, and that
preventing this completion somehow solves this problem. I fail to see how the
ability to complete the struct type would be a problem without prototype scope.

Or perhaps you mean that the inability to refer to the incomplete struct type
later is the problem. That's what you seem to be indicating here:

> Its type is not the type of anie of these,
>=if later declared:
>=	struct S
>=	{	char f;
>=	};
>=or
>=	struct S
>=	{	int f;
>=	};
>=or
>=	struct S
>=	{	double f;
>=	}
>> I know that. That's the problem.
>I know not what you mean,

What I mean is this: If the inability to later refer to the incomplete type
(in an attempt to complete it, for example) by one of the above constructs you
listed, is what you see as THE PROBLEM, then all I am saying is that function
prototype scope is the REASON this problem exists. Function prototype scope
doesn't *solve* the problem, or help the compiler cope with the problem, but
rather *causes* this problem. If there were no function prototype scope, the
incomplete structure type declared would have file scope, and would therefore
be completable by one of the above constructs. It is the presence of
function-prototype scope that *causes* this problem of yours.

> but I see a problem in seeing hou to generate
>code for a pointer ere that which the pointer points to is known.

Huh? You say it's ok to generate code for pointers to incomplete types, but
handling pointers to complete types is a problem? What do you think the
compiler does with "pointer to int"? With a pointer to int, what the pointer
points to is certainly known. Why is that a problem?

>
>> How so? It's impossible to use the declared function now, so how are any
>> problems "swept under the rug" as a result of having prototype scope? I stand
>> by my claim that it is still possible and mandatory to declare the complete
>> structure type before the prototype.
>Well, yes, not declaring it raizes a problem, with a "solution" that forbids
>use of the so declared function.

Without prototype  scope this problem wouldn't exist at all.

You have yet to give an example of why things would be bad if there were no
such thing as function prototype scope (other than the parameter namespace
collision problem I already pointed out). Nor have you responded to my point
that compilers generated code just fine when there were no such thing as
prototypes at all, let alone prototype-scope.

--

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