🚀 go-pugleaf

In article mkf@franklin.its.utas.edu.au, vmm@tasman.its.utas.edu.au (Vishv Malhotra) writes:
>
>In the following function a++; is acceptable but b++; is not.
>
>	void foo(int a[20]) {
>		int b[20];
>
>		a++;
>		b++;
>	}
>
>I understand the reason, but I wish to know if there is any thought
>on elimination the anomaly?

You can modify 'a' because its declaration is implicitly rewritten by the
compiler to "int *a".  That is, even though its declaration looks like an
array, "a" is really a pointer variable.

You cannot modify 'b' because it is the name of an array, and represents
its address. For example, the following is disallowed for the same reason:
	int x;
	(&x)++; /* error */

How would you go about either forbidding a++ or allowing b++, without
also making fundamental changes throughout the language?

Personally, I think the array/pointer schizophrenia in C was a mistake, as
it leads to endless confusion and prevents using arrays as first-class
objects. But changing the current relationship of pointers and arrays in C
would break all existing C programs, since even the declaration of main
relies on it.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <4ikp70$mkf@franklin.its.utas.edu.au>
           vmm@tasman.its.utas.edu.au "Vishv Malhotra" writes:

>
>In the following function a++; is acceptable but b++; is not.
>
>        void foo(int a[20]) {
>                int b[20];
>
>                a++;
>                b++;
>        }
>
>I understand the reason, but I wish to know if there is any thought
>on elimination the anomaly?

That would gratuitously break existing code for no practical gain.

You refer in the subject line to A7.1 which in K&R describes how in an
expression an array evaluates to a non-lvalue pointer to its first element.
That explains why b++ is illegal (since ++ requires its operand to be an
lvalue) but is not relevant to a. That is because a declaration is not an
expression and a different rule (commonly called the rewrite rule) applies
to function parameters. In essence a parameter of type array of T is
rewritten to have type pointer to T. So the definition of foo() above means
precisely the same thing as one defined as:

         void foo(int *a) {
           ...
         }

Clearly this mirrors the rule for array evaluation (and there is a similar
case for functions/function pointers) but the rewrite rule affects the
fundamental type of an object rather than just the value derived from it.
In a++ in the code above ++ is genuinely being applied to a pointer object
and, for example, sizeof a == sizeof(int *). a really is a pointer whereas
b is not.

I suppose you could eliminate the rewrite rule for arrays but I don't
think that would be helpful. It would also generate as many anomalies as
it eliminates.

>Perhaps, I should state my problem more clearly, in K&R on page 115
>where command line arguments are being explained the diagram for argv
>corresponds to the declaration
>
>        char *(*argv)[]

No, it corresponds to:

         char **

'Pointer to an array' tends to be used rather loosely to mean 'pointer to
an element (usually the first) of an array'. The point is that once you
can address one element of an array you can address all of the others using
pointer arithmetic so, for instance when you have:

    int a[10];
    int *i = a;

you can use i to address any element of a. Some (including K&R seemingly)
say that i points to array a. IMHO this is a poor description but it is a
usage you have to be aware of.

>I have never seen such a declaration! Nor does this seem to work on
>my compiler. Is the diagram on page 115 not true representation of
>ANSI C standard?

I think the arrow from argv should point inside the the box that represents
the array to the first element, not just at the box itself. K&R is really
just following diagramatically the loose usage of terminology.

Note that unless your question is directly relevant to the contents of
the ANSI/ISO C standard document rather than the C language in general you
should post it to comp.lang.c or comp.lang.c.moderated. K&R no longer
holds the position of language standard (not even the appendices).

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------