From: utzoo!decvax!cca!Steve@sri-unix
Newsgroups: net.unix-wizards
Title: Re: C question
Article-I.D.: sri-unix.1987
Posted: Thu Jul  1 01:45:45 1982
Received: Thu Jul  1 07:02:55 1982

Date: 20 Jun 1982 21:34:51 EDT (Sunday)
Regarding the Onyx Z8000 C compiler's problems with extraneous
ampersands, I would not say that the compiler is broken, just that it is
unnecessarily strict.  "Standard C", i.e. the Ritchie PDP-11
compiler allows one to add ampersands before expressions which
don't really need them because in early UNIX code, one often found
constructs of the form:

/* in one file */
main()
{
	extern foo;

	func = &foo;
	(*func)();
}

/* in another file */
foo()
{
	/* blah blah */
}

In other words, in the main procedure, the subroutine foo was being treated
like an "extern int", and because of the PDP-11 architecture, there was no
problem.  This was very common in V6-vintage programs, though I seem to see
less of it these days.  I suspect the construct was allowed to continue
because of the hassle it would cause otherwise.

The same goes for arrays.  There is one peculiarity though (in the Ritchie
PDP-11 compiler--I have not verified the results for any others):

If one says,
int x[10];

both x and &x resolve to the same value, the address of the first
element of the array.  However, the implicit size of these pointer
objects is different:

x+1 points to the second element of the array (equiv. to &x[1])

&x + 1 points to the 1st memory location AFTER the end of x (i.e.,
1 is multiplied by the entire size of the array x).

So, in this case, x and &x don't really mean the same thing, though
they point to the same memory location!

Hope these tidbits shed a bit more light on the subject, though
I feel you've probably got a fair amount of editting to do.  Neither
construct is mentioned in the C reference manual, presumably the bible for all
those who didn't start with the Ritchie compiler.