Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!acf3!sabbagh
From: sabbagh@acf3.NYU.EDU (sabbagh)
Newsgroups: comp.lang.c
Subject: Re: Clarification needed on Pointers/Arrays
Message-ID: <890@acf3.NYU.EDU>
Date: 23 Feb 89 17:54:36 GMT
References: <1436@etive.ed.ac.uk> <889@acf3.NYU.EDU> <11840@haddock.ima.isc.com>
Reply-To: sabbagh@acf3.UUCP ()
Organization: New York University
Lines: 66

In article <11840@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <889@acf3.NYU.EDU> sabbagh@acf3.UUCP () writes:
>>In article <1436@etive.ed.ac.uk> sam@lfcs.ed.ac.uk (S. Manoharan) writes:
>
>>Now, according to K & R, the notation
>>	p1[j]
>>is in ALL WAYS equivalent to
>>	*(p1 + j)
>
>Minor nit: they are equivalent in expressions, but not in declarations.

Agreed.

>
>>(Incidentally, this implies that p1[j] == j[p1]) !!
>
>A fact used primarily by the Obfuscated C Contestants.  I wish X3J11 had fixed
>this.  (They could use the same justification that they did for fixing `+ ='.)
>
>>So what are arrays?  They are POINTER CONSTANTS.
>
>Urk.  While this is true in a sense, it's been my observation that people who
>think of them that way are taking the wrong path to understanding.

Hmm. It depends on what you are trying to understand.  If you are trying to 
USE C, then it's the perfect way to understand them.

>It becomes
>a pointer after the transformation (array-valued expressions decay into
>pointer-valued expressions when used in an rvalue context), in which case its
>value is constant throughout its lifetime.  This is independent of its lvalue
>properties, but some people believe that this is the reason that the lvalue is
>not modifiable.  This is not the case; it would be a relatively simple
>extension to the language to allow array copy.  (It is hindered only by the
>fact that X3J11 didn't fix the declaration botch noted in the first warning
>message above (and in fact paved the way for reinterpreting it according to
>the Darnell syntax rather than the more logical Brader-Heuer syntax), and by
>the opinion that array copy with compile-time array sizes is not especially
>useful.)

I have a slightly different philosophy than you.  I use C as I can find it.
I use it on a whole bunch of flavors of UN*X and also Turbo C 2.0 at home.
The fact is, X3J11 DID NOT make the changes and C compilers treat the name
of an array as a constant.

Also, this is the way most people view C if they are ex-assembly language
programmers.  At NYU, I teach C as "portable assembly language" with some
success, and that is the way I understand it.

One explanation for why X3J11 did not "fix" the "declaration botch" is 
because it would change the way many systems programmers use C. I believe 
that things in C are the way they are in order to make it as close to
assembly language as possible and still be portable.  Thus something like

	int a[10],b[10];
	...
	a = b;

is easy enough to interpret as array copy, but it be a "high-level" construct
that is not found in other semnatic areas of C.

Before you start flaming me about machine architectures that support 
multi-word copies in one instruction (e.g. 8086 MOVS), remember that C
was developed in the early '70s on a PDP 11 which did not have such
instructions.  I guess that really means that it isn't such a bad idea
to allow array copies now ;-).