gcc: pointer to array

[Alexei A. Frounze]

Hi all,

I have a question regarding the gcc behavior (gcc version 3.3.4).

On the following test program it emits a warning:
#include <stdio.h>

int aInt2[6] = {0,1,2,4,9,16};
int aInt3[5] = {0,1,2,4,9};

void print1 (const int* p, size_t cnt)
{
while (cnt--)
printf ("%d\n", *p++);
}

void print2 (const int (*p)[5])
{
size_t cnt;
#if 0
// prohibited:
(*p)[0]=0;
#endif
for (cnt=0; cnt<5; cnt++)
printf ("%d\n", (*p)[cnt]);
}

int main()
{
printf ("test begin\n");

print1 (aInt2, sizeof(aInt2)/sizeof(aInt2[0]));
print2 (&aInt3); // <-- warns here

printf ("test end\n");
return 0;
}

The warning is:
MOD.c: In function `main':
MOD.c:: warning: passing arg 1 of `print2' from incompatible pointer type

Why is that? How is this different from using print1 (aInt2, ...)? All I
want to do is to explicitly show that the pointer is to an array of 5
entries and ensure that it's not modified in anyway inside print2(). However
the #if 0'd assignment operator inside print2() is correctly handled by
gcc -- an error is generated:
MOD.c: In function `print2':
MOD.c:: error: assignment of read-only location
What's wrong with gcc?

There's another thing about the pointer to the array is... The compiler
doesn't generate a warning if I change in print2()
for (cnt=0; cnt<5; cnt++)
to
for (cnt=0; cnt<6; cnt++)
and lets me access (*p)[5], though I think at least a warning should be
generated here.
It doesn't warn me if I put
aInt3[6] = 0;
into main(). But in both cases the compiler "knows" the real size of the
array, still no warning...
Is this OK???

Thanks,
Alex
P.S. I compile it as gcc MOD.c -Wall -oMOD.exe

[Peter Nilsson]

Ben Pfaff wrote:

"Maxim S. Shatskih" <ma***@storagec raft.com> writes:

With "const", all is clear. The "const" attribute of the lvalue cannot be
removed without the explicit cast - neither in C nor on C++.

Sure it can--try calling a function like strchr().

Or just...

char *foo();

void bah(const char *x)
{
char *y = foo(x);
...
}

char *foo(char *x)
{
return x;
}

--
Peter

[Netocrat]

On Wed, 13 Jul 2005 23:17:57 -0700, Peter Nilsson wrote:

Ben Pfaff wrote:

"Maxim S. Shatskih" <ma***@storagec raft.com> writes:

> With "const", all is clear. The "const" attribute of the lvalue cannot
> be removed without the explicit cast - neither in C nor on C++.

Sure it can--try calling a function like strchr().

Or just...

char *foo();

void bah(const char *x)
{
char *y = foo(x);
...
}
}
char *foo(char *x)
{
return x;
}

Neither of these examples removes a const attribute from an lvalue, which
is impossible by definition. An lvalue can be assigned to. If it had a
const attribute that was to be removed, you couldn't assign to it and it
wouldn't be an lvalue in the first place.

I believe though that you've correctly interpreted what Maxim meant as
opposed to what actually said.

[Maxim S. Shatskih]

> > char *foo();

Oh, sorry. The only language for which I've read the formal description was C++
(old one - circa 1993) and not C. In C++, such things are impossible.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecr aft.com
http://www.storagecraft.com

[Fabio Alemagna]

Andrey Tarasevich wrote:

It is not "indexed in a different way". All arrays, single- or
multi-dimensional, are indexed in exactly the same way.

Nope, they're not. The equivalence stops at one-dimensional arrays.
Multidimensiona l arrays aren't addressed the same way as
multi-indirectioned (sp?) pointers.

That is to say, int foo[10][20] doesn't decay to int **.

Multi-dimensional arrays store all of their elements consecutively, the
single elements are accessed by means of pointer math on the dimensions
and size of the elements, whilst multi-indirectioned pointers are simply
pointers (to pointers... to pointers) to the elements:
int foo[3][3] :

+--+--+--+
| | | |
+--+--+--+
| | | |
+--+--+--+
| | | |
+--+--+--+

int **baz :

+--+--+--+ ...
| | | | ...
+--+--+--+ ...
|| || ||
\/ \/ \/
+--+--+--+
| + + |
+--+--+--+
| + + |
+--+--+--+
| + + |
+--+--+--+
...........
...........
...........
--
Fabio Alemagna

[Netocrat]

On Thu, 14 Jul 2005 10:40:50 +0400, Maxim S. Shatskih wrote:

> char *foo();

Oh, sorry. The only language for which I've read the formal description
was C++ (old one - circa 1993) and not C. In C++, such things are
impossible.

Actually assuming you that by "lvalue" you meant "expression " what you
said was correct anyway. You said that the const attribute cannot be
removed from an expression without an explicit cast, which is true.

Looking again at the examples given by Ben Pfaff and Peter Nilsson,
they're showing the const attribute being added, rather than removed,
without an explicit cast.

[Andrey Tarasevich]

Fabio Alemagna wrote:

It is not "indexed in a different way". All arrays, single- or
multi-dimensional, are indexed in exactly the same way.
Nope, they're not.

Yes, they are.
The equivalence stops at one-dimensional arrays.
Multidimensiona l arrays aren't addressed the same way as
multi-indirectioned (sp?) pointers.
That's true. But in my message I'm talking about the difference between
the way single- and multi-dimensional arrays are addressed. No pointers
involved (multi-indirectioned or not). You for some reason start talking
about pointers. Why?
That is to say, int foo[10][20] doesn't decay to int **.
That's true. But, once again, how is this relevant?
[skipped]

Once again, true. But I still don't see how all this applies to what I
said in my message.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Netocrat wrote:

...
Neither of these examples removes a const attribute from an lvalue, which
is impossible by definition. An lvalue can be assigned to.
Huh? No. By definition, lvalue is something that has address in storage. In
general case lvalue cannot be assigned to. Only _modifyable_ lvalue can be
assigned to, but there are also non-modifyable lvalues.
If it had a
const attribute that was to be removed, you couldn't assign to it and it
wouldn't be an lvalue in the first place.

Not true. You seem to assume that assignability is a defining property of
"lvalueness ". That's simply not true.

--
Best regards,
Andrey Tarasevich

[Netocrat]

On Thu, 14 Jul 2005 02:47:13 -0700, Andrey Tarasevich wrote:

Netocrat wrote:

...
Neither of these examples removes a const attribute from an lvalue, which
is impossible by definition. An lvalue can be assigned to.
Huh? No. By definition, lvalue is something that has address in storage. In
general case lvalue cannot be assigned to. Only _modifyable_ lvalue can be
assigned to, but there are also non-modifyable lvalues.

Right, my concept of lvalue was slightly out. Non-modifiable being for
example arrays and structs.

Maxim's original statement then is accurate:
With "const", all is clear. The "const" attribute of the lvalue cannot
be removed without the explicit cast - neither in C nor on C++.

If it had a
const attribute that was to be removed, you couldn't assign to it and it
wouldn't be an lvalue in the first place.

Not true. You seem to assume that assignability is a defining property of
"lvalueness ". That's simply not true.

On reading the standard I see that you are correct.

[CBFalconer]

Fabio Alemagna wrote:

Andrey Tarasevich wrote:

It is not "indexed in a different way". All arrays, single- or
multi-dimensional, are indexed in exactly the same way.

Nope, they're not. The equivalence stops at one-dimensional arrays.
Multidimensiona l arrays aren't addressed the same way as
multi-indirectioned (sp?) pointers.

That is to say, int foo[10][20] doesn't decay to int **.

Which is because there are no multi-dimensioned arrays in C, there
are just arrays of arrays. An array of pointers is not a
multidimensione d array, or even a fake of one linearized.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[S.Tobias]

In comp.lang.c Peter Nilsson <ai***@acay.com .au> wrote:

char *foo();

void bah(const char *x)
{
char *y = foo(x);
You raise UB here: (const char*) and (char*) types are
not compatible - you cannot pass incompatible arguments
to a function call (cf. 6.5.2.2#6).
...
}

char *foo(char *x)
{
return x;
}

--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`