🚀 go-pugleaf

>>       int array[100];                 int array[100];
>>       int *p;                         int i;
>>       extern int *bar();              extern int bar();
>>
>>       foo ()                          foo ()
>>       {                               {
>>               p = bar();                      i = bar();
>>               *p = 42;                        array[i] = 42;
>>       }                               }
>
>Yes, but the problem is not whether foo() in isolation is more efficient
>but whether the _program_ as a whole is more efficient.  In this case,
>in order for these two programs to have the same semantics, the base of
>array[] must be added into p.  Whether this add is done in foo() or in
>bar(), it still takes the same time to do.

Nonsense.  The base of array[] can be "added into p" statically:

	extern int array[100];

	int *bar ()
	{
		return array+8;
	}

Your points about aliasing are well taken (you've repeated them often enough);
I only take issue with the claim that there can *never* be an efficiency
advantage to pointers.  In an earlier post, I mentioned that the abstract they
can provide (virtual machine addresses) are useful to writers of loaders.  You
replied in mail that you had written a loader using only arrays, which is fine,
but it does not change the fact the the abstraction of an actual virtual
address can be useful (your array implementation merely substitued integer
indices for pointers to achive the same abstraction).

Certainly some implementations of pointers can cause aliasing problems in
optimizers; no one disputes that.  This does not change the inherent usefulness
of the abstraction, or the fact that there are cases where pointers can give
you a win (especially in an implementation with more restricted aliasing).