[comp.lang.c++] Type of address of array

mikeb@inset.UUCP (Mike Banahan) (10/12/90)

Here is an interesting "feature" of the Zortech R2.1, Borland and AT&T R2.0
C++ compilers:

main(){
	typedef int iar[4];

	iar localitem;
	iar *iap;

	iap = &localitem;	// type error - address of localitem
				// is not of type int (*)[4]
}

This, whilst correct in Old C (address of an array is not a meaningful
operation), is not correct by the rules of ANSI C, where the address of
an array is a pointer to the whole array.

Ellis and Stroustrup, 5.3, does say that the operand of & must be an lvalue,
but I can hardly think that this is what was intended. Ho humm.

The important point in this is not so much that I can't get around it,
but that it blows up when I try to apply new() to one of these:

	iap = new iar;

which is a pain in the rear end and no mistake. Perhaps somebody has some
insight into how to avoid this apart from just kludging it with casts?

Mike Banahan
-- 
Mike Banahan, Technical Director, The Instruction Set Ltd.
mcvax!ukc!inset!mikeb

ark@alice.att.com (Andrew Koenig) (10/13/90)

In article <1649@inset.UUCP>, mikeb@inset.UUCP (Mike Banahan) writes:

> Here is an interesting "feature" of the Zortech R2.1, Borland and AT&T R2.0
> C++ compilers:

> main(){
> 	typedef int iar[4];
> 
> 	iar localitem;
> 	iar *iap;

> 	iap = &localitem;	// type error - address of localitem
> 				// is not of type int (*)[4]
> }

> This, whilst correct in Old C (address of an array is not a meaningful
> operation), is not correct by the rules of ANSI C, where the address of
> an array is a pointer to the whole array.

First you say it's correct, then you say it's `not a meaningful
operation!'  Those statements can't both be true...

In fact, &localitem is an error in K&R C but is valid in ANSI C.

Cfront 2.0 accepts it, but is unfortunately incapable of generating
C that a K&R compiler will accept.  If you are driving an ANSI compiler,
it works fine.

> Ellis and Stroustrup, 5.3, does say that the operand of & must be an lvalue,
> but I can hardly think that this is what was intended. Ho humm.

No reason not to consider localitem as an lvalue -- you can take
its address, after all.  &localitem is indeed valid C++; it's just
that it's hard to know how to translate such a beast into K&R C.  I'll
think about it, though.

> The important point in this is not so much that I can't get around it,
> but that it blows up when I try to apply new() to one of these:

> 	iap = new iar;

> which is a pain in the rear end and no mistake. Perhaps somebody has some
> insight into how to avoid this apart from just kludging it with casts?

Ah, that's because if you say `new T' and T is an array type, that
means `allocate an array but return a pointer to its initial element.'

If you really want to allocate an `iar' array and return a pointer to
the array, you must say

	iap = new iar[1];

Yes I know that's a little weird, but there's no other way to allow

	typedef char buffer[100];
	char* p = new buffer;

which one would also naively expect to work.
-- 
				--Andrew Koenig
				  ark@europa.att.com