pointer to array of const objects

[x-pander]

given the code:

<file: c.c>
typedef int quad_t[4];

void w0(int *r, const quad_t *p)
{
*r = (*p)[0];
}

int main()
{
quad_t m = {0};
int r;
w0(&r, &m);
return 0;
}
</file>

why does the cc produce:

<quoting respectful cc>
c.c: In function `main':
c.c:12: warning: passing arg 2 of `w0' from incompatible pointer type
</quoting>

how do i write function's w0 prototype correctly, to make it say that arg 2
of w0 is a pointer to an array, content of which is not modified by the
function?

--
x-pander

[Mike Wahler]

"x-pander" <ng***@pitek.eu.org> wrote in message
news:ct***********@mamut1.aster.pl...

given the code:

<file: c.c>
typedef int quad_t[4];

void w0(int *r, const quad_t *p)
{
*r = (*p)[0];
}

int main()
{
quad_t m = {0};
int r;
w0(&r, &m);
return 0;
}
</file>

why does the cc produce:

<quoting respectful cc>
c.c: In function `main':
c.c:12: warning: passing arg 2 of `w0' from incompatible pointer type
</quoting>

how do i write function's w0 prototype correctly, to make it say that arg 2 of w0 is a pointer to an array, content of which is not modified by the
function?

What you have looks correct to me. Are you sure that's
the exact code giving the error?

-Mike

[x-pander]

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:yJ*****************@newsread3.news.pas.earthl ink.net...
[...]

What you have looks correct to me. Are you sure that's
the exact code giving the error?

i am.
checked with gcc 2.95.4 and 4.0.0 (experimental)

of course it works ok, if i modify the prototype from:
void w0(int *r, const quad_t *p);
to:
void w0(int *r, quad_t *p);

--
x-pander

[Mike Wahler]

"x-pander" <ng***@pitek.eu.org> wrote in message
news:ct**********@mamut1.aster.pl...

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:yJ*****************@newsread3.news.pas.earthl ink.net...
[...]

What you have looks correct to me. Are you sure that's
the exact code giving the error?

i am.
checked with gcc 2.95.4 and 4.0.0 (experimental)

of course it works ok, if i modify the prototype from:
void w0(int *r, const quad_t *p);
to:
void w0(int *r, quad_t *p);

A parameter defined as a pointer to a const object
should accept a pointer to a nonconst object, but
not the other way around. Unless there's something
I'm missing (or you're not telling), it seems to
me the compiler is wrong.

-Mike

[x-pander]

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:NX*****************@newsread3.news.pas.earthl ink.net...

of course it works ok, if i modify the prototype from:
void w0(int *r, const quad_t *p);
to:
void w0(int *r, quad_t *p);

A parameter defined as a pointer to a const object
should accept a pointer to a nonconst object, but
not the other way around. Unless there's something
I'm missing (or you're not telling), it seems to
me the compiler is wrong.

well i do strongly doubt that gcc is wrong
note, that what we have here is not a pointer to const object, but a pointer
to array of const objects, which (it seems) somehow breaks the normal rules
of const qualifiied type compatibility

i (kindly) demand explanation

--
x-pander

[E. Robert Tisdale]

x-pander wrote:

Given the code:

<file: c.c>
typedef int quad_t[4];

void w0(int *r, const quad_t *p) {
*r = (*p)[0];
}

int main() {
quad_t m = {0};
int r;
w0(&r, &m);
return 0;
}
</file>

why does the cc produce:

<quoting respectful cc>
c.c: In function `main':
c.c:12: warning: passing arg 2 of `w0' from incompatible pointer type
</quoting>

How do I write function's w0 prototype correctly
to make it say that arg 2 of w0 is a pointer to an array
[the] content of which is not modified by the function? cat c.c #include <stdio.h>

typedef int quad_t[4];

void w0(int *r, const quad_t p) {
*r = p[0];
}

int main(int argc, char* argv[]) {
quad_t m = {0, 1, 2, 3};
int r;
fprintf(stdout, "m = (");
for (size_t j = 0; j < 4; ++j)
fprintf(stdout, " %d", m[j]);
fprintf(stdout, ")\n");
w0(&r, m);
fprintf(stdout, "r = %d\n", r);
return 0;
}
gcc -Wall -std=c99 -pedantic -o c c.c
./c

m = ( 0 1 2 3)
r = 0

`const quad_t p' is a synonym for `const int p[4]' and
`quad_t m' is a synonym for `int m[4]'.

[Andrey Tarasevich]

Mike Wahler wrote:

[...]

> What you have looks correct to me. Are you sure that's
> the exact code giving the error?

i am.
checked with gcc 2.95.4 and 4.0.0 (experimental)

of course it works ok, if i modify the prototype from:
void w0(int *r, const quad_t *p);
to:
void w0(int *r, quad_t *p);

A parameter defined as a pointer to a const object
should accept a pointer to a nonconst object, but
not the other way around. Unless there's something
I'm missing (or you're not telling), it seems to
me the compiler is wrong.
...

Unfortunately, the compiler is right. That's one of the issues caused by
arrays being "second-rate citizens" in C.

In C 'const' qualifier applied to array type 'quad_t' "falls through" to
actual array elements, i.e. 'const quad_t' is 'const int[4]'. It is
simply impossible to apply 'const' qualifier to array type itself. Any
attempts to do so will lead to the above "fall through" behavior and the
qualifier will be applied to the type of array elements, not to the
array type itself. For this reason, type 'const quad_t' is not
considered to be a const-qualified version of type 'quad_t' and the
conversion from 'quad_t*' to 'const quad_t*' is not allowed.

--
Best regards,
Andrey Tarasevich

[Nick Austin]

On Wed, 26 Jan 2005 02:29:33 +0100, "x-pander" <ng***@pitek.eu.org>
wrote:

typedef int quad_t[4];

void w0(int *r, const quad_t *p)
{
*r = (*p)[0];
}

int main()
{
quad_t m = {0};
int r;
w0(&r, &m);
gcc accepts this code if you write:
w0(&r, (void *)&m);

I'm not sure why.

Nick.
return 0;
}

[Mike Wahler]

"Nick Austin" <se*********************@nospam.com> wrote in message
news:aj********************************@4ax.com...

On Wed, 26 Jan 2005 02:29:33 +0100, "x-pander" <ng***@pitek.eu.org>
wrote:

typedef int quad_t[4];

void w0(int *r, const quad_t *p)
{
*r = (*p)[0];
}

int main()
{
quad_t m = {0};
int r;
w0(&r, &m);

gcc accepts this code if you write:
w0(&r, (void *)&m);

I'm not sure why.

Because the cast discards the const qualifier.

Btw thanks, Andrey, I learned something new today
(I've never had cause to try writing anything like
'x-pander' did, so his issue has never arisen
for me.)

-Mike

[Michael Wojcik]

In article <aj********************************@4ax.com>, Nick Austin <se*********************@nospam.com> writes:

On Wed, 26 Jan 2005 02:29:33 +0100, "x-pander" <ng***@pitek.eu.org>
wrote:

typedef int quad_t[4];

void w0(int *r, const quad_t *p)
{
*r = (*p)[0];
}

int main()
{
quad_t m = {0};
int r;
w0(&r, &m);

gcc accepts this code if you write:
w0(&r, (void *)&m);

I'm not sure why.

Because void * can be converted to any object pointer type, including
const int[4] *, which is what const quad_t * is an alias for.

One way to avoid the const "fall-through" Andrey described, which is
what's giving x-pander trouble, would be to make quad_t a structure
rather than an array. However, in this case, I think the fall-through
is actually what x-pander wants:

"arg 2 ... is a pointer to an array, content of which is not
modified by the function"

seems to me to say that, indeed, pointer-to-array-of-four-const-int
is the right type for the parameter. The real issue isn't that the
array "itself" can't be const-qualified; it's that such a type isn't
compatible with pointer-to-array-of-four-int, which is what he wants
to pass.

In this case, it's probably best just to drop the const qualifier
from the function declaration. The alternative is to cast the
actual argument, which seems to me to cost more than it's worth.

--
Michael Wojcik mi************@microfocus.com

I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_

[x-pander]

"Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:ct********@news1.newsguy.com...

In article <aj********************************@4ax.com>, Nick Austin
<se*********************@nospam.com> writes:

On Wed, 26 Jan 2005 02:29:33 +0100, "x-pander" <ng***@pitek.eu.org>
wrote:

>typedef int quad_t[4];
>
>void w0(int *r, const quad_t *p)
[...]

One way to avoid the const "fall-through" Andrey described, which is
what's giving x-pander trouble, would be to make quad_t a structure
rather than an array. However, in this case, I think the fall-through
is actually what x-pander wants:

i was also thinking of making this type:
typedef struct {
int word[4];
} quad2_t;
which would work as excpected, but it felt rather artificial to me to
encapsulate an array inside a struct.
however I think i'm going to use that, one question i have:
am i guaranteed that quad2_t type has exactly same memory representation as
quad_t, so that:
sizeof(quad2_t) == sizeof(quad_t) == 4*sizeof(int)
and the alignment is the same:
quad2_t m;
(*(quad_t *)&m)[0] = 0; /* is this valid ? */
seems to me to say that, indeed, pointer-to-array-of-four-const-int
is the right type for the parameter. The real issue isn't that the
array "itself" can't be const-qualified; it's that such a type isn't
compatible with pointer-to-array-of-four-int, which is what he wants
to pass.

that is exactly the problem.
it's a real shame that in C "pointer-to-array-of-four-int" is an not
compatible with "pointer-to-array-of-four-const-int".
could someone explain me the rationale behind this incompatibility?
also how exactly does the c99 standard explicitly states that?

--
x-pander

[Michael Wojcik]

In article <ct***********@mamut1.aster.pl>, "x-pander" <ng***@pitek.eu.org> writes:

"Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:ct********@news1.newsguy.com...

In article <aj********************************@4ax.com>, Nick Austin
<se*********************@nospam.com> writes:

On Wed, 26 Jan 2005 02:29:33 +0100, "x-pander" <ng***@pitek.eu.org>
wrote:
One way to avoid the const "fall-through" Andrey described, which is
what's giving x-pander trouble, would be to make quad_t a structure
rather than an array.

i was also thinking of making this type:
typedef struct {
int word[4];
} quad2_t;
which would work as excpected, but it felt rather artificial to me to
encapsulate an array inside a struct.

It may feel artificial to you, but remember that "struct" is the C
keyword for creating new types; "typedef" only creates an alias. If
you want a type that behaves like a type, use struct. (Personally,
I'd use struct and skip the typedef; I think typedef is rarely
actually useful. But opinions differ on this question.)

You can always set an int* to the .word member inside each function
if you don't want to qualify every access:

void foo(const quad2_t *quad)
{
int *qdata;

if (! quad) return;
qdata = quad->word;
...
}
however I think i'm going to use that, one question i have:
am i guaranteed that quad2_t type has exactly same memory representation as
quad_t, so that:
sizeof(quad2_t) == sizeof(quad_t) == 4*sizeof(int)
and the alignment is the same:
quad2_t m;
(*(quad_t *)&m)[0] = 0; /* is this valid ? */
Hmm. There can't be padding before the first member of a structure,
and you only have one member here. There *can* be padding at the end
of a structure, and in fact there must be if any would be needed
between items in an array of that structure. In this case, though,
any reasonable implementation ought to be aligning an array of quad2_t
just as it would align an array of int, since that's all that quad2_t
contains.

The real issue isn't that the
array "itself" can't be const-qualified; it's that such a type isn't
compatible with pointer-to-array-of-four-int, which is what he wants
to pass.

that is exactly the problem.
it's a real shame that in C "pointer-to-array-of-four-int" is an not
compatible with "pointer-to-array-of-four-const-int".
could someone explain me the rationale behind this incompatibility?

I suspect the committee felt that it was an unreasonable burden to
impose more complex const-conversion rules on implementors. (This is
actually a conversion rule, not a compatibility rule.) The one we
have - pointer to T can be converted to pointer to const T - is
pretty simple and easy for implementors to get right.

The conversion you want - from pointer-to-array-of-T to pointer-to-
array-of-const-T - requires "pushing" the const conversion one step
further. If they allowed that, they'd probably have to allow things
like pointer-to-struct-containing-T to pointer-to-struct-containing-
const-T, and clearly things are getting much more complicated when
the implementation has to figure out if any consts are being added
anywhere in the conversion process.
also how exactly does the c99 standard explicitly states that?

I don't have a copy of C99 (must remember to get it from the ANSI
store...), just a copy of the final draft. C90 says:

[#2] For any qualifier q, a pointer to a non-q-qualified
type may be converted to a pointer to the q-qualified
version of the type; the values stored in the original and
converted pointers shall compare equal. (n869 6.3.2.3)

That says that the conversion is allowed. What makes it happen
automatically is:

-- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to
by the left has all the qualifiers of the type pointed
to by the right; (n869 6.5.16.1 #1)

This is part of the "simple assignment" rules, which (AIUI) apply in
this case. Note that the destination must have all the qualifiers of
the source, but not vice versa.

And 6.5.4 says that any pointer conversion not covered by 6.5.16.1
requires an explicit cast.

--
Michael Wojcik mi************@microfocus.com

This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation