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.