🚀 go-pugleaf

In article <43qjdk$loj@caip.rutgers.edu>, halasz@caip.rutgers.edu writes:
>In article <43pdgk$b3i@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes
>> ....
>> 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).
>I hav, but you ignord it.

No you haven't, even in what follows:

>  Consider the PDP-11: pointer to 'char' and
>pointer to 'int' need different-"shaped" pointers.  For generating
>right argument-passing code for it, the compiler needs to know which it
>is.

a) It only needs to know which it is if you want the compiler to do the
implicit conversion for you. In old K&R C, the programmer was responsible for
making sure he didn't pass a char* to a routine that accepts an int*.

b) And if you want the compiler to do the implicit conversion for you, you
can specify the correct prototype WITHOUT, I repeat, *WITHOUT* relying upon
the existence of function-prototype scope for this to work.

>  A 'struct' with one field a compiler is free in code to treat as
>if it were onlie that which it contains. 

Gibberish. What are you saying? That a compiler is allowed to treat an object
of type "struct {int a;}" as if it were of type "int"? Says who? And even so,
what difference would that make?

> Prototype-scope is a solution
>by forbidding calling a so declared function.

Solution? How? You just said that function-prototype (henceforth "f-p") scope
is necessary for the generation of correct code. How much code gets generated
for a rejected translation unit? Rejecting code that could otherwise be
meaningful and correct is not a solution. And you have yet to give an example
of a piece of code that works properly (i.e. is correct, not rejected) due to
the existence of f-p scope that would somehow become ambiguous or otherwise
non-executable without f-p scope.

>
>> 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.

>C was implemented onlie on byte-addressd machines?  I am quite sure that
>that was so.

Not relevant. K&R C is implementable on machines in which char* and int* are
even passed in different types of registers!

>  But the real answer is that the compiler was not required
>to match argument and parameter.  If the programmer goofd and passd
>byte-pointer to word-pointer or converslie, the compiler nevver would know.

That's not what I asked. My point was that compilers for K&R C were able to
generate correct object code for correct C code. They were able to do this
without prototypes, and therefore they were able to do it without f-p scope. 
So your argument that it is somehow not possible to generate correct object
code from correct source without f-p scope is wrong. 

Secondly, if you are trying to point out that prototypes allow the compiler to
diagnose passing incompatible parameter types or perform implicit conversions
that they would otherwise not be able to do, I have already pointed out that
fact. But remember that it is prototypes themselves, not f-p scope, that
allows this to occur.



>Even with byte-addressd processors the like can be, if the processor
>requires alignment and pointer of lesser alignment is passd: Bus error.

And f-p scope is somehow relevant to the above statement? (That was a
rhetorical question. The anser is, "it isn't".)

>
>All the same, I doubt my explanation, for there are quite a few hacks that
>go around it.  This one was posted,
>	struct S;
>	int k(struct S *);

Right. The above code is legal, and the declared function can be used in a
meaningful way. The point is that without f-p scope, you don't need the
initial struct S declaration. It becomes implied.

>and I hav uzed this,
>	typedef struct S junkName;
>	int k(struct S *);
>.  Nor explains this this,
>	int k(struct S { char k; });
>and the like.
>
>I doubt that the thing servs anie real purpose.
              ^^^^^^^^^
What is "the thing"? F-p scope? If so, then I'm glad that is clear now.

Of course, as I said before, f-p scope is useful for one thing: being able to
have header files with comprehensible prototypes like:

	int foobar(int window, float color);

without corrupting the user's namespace with identifiers "window" and
"color".


--

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