By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,191 Members | 812 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,191 IT Pros & Developers. It's quick & easy.

const parameter problem - clarification needed

P: n/a
Consider the following program:

#include <stdio.h>

void myfn(const int **a)
{
static int i, j, k;

a[0] = &i;
a[1] = &j;
a[2] = &k;

return;
}

int main(void)
{
int *a[3];
int x, y, z;

a[0] = &x;
a[1] = &y;
a[2] = &z;

x = 10;
y = 20;
z = 30;

myfn(a);

return 0;

}

Suppose the program name is tmp.c

When this program is compiled with gcc under Redhat Enerprise Linux,
with the command
gcc -std=c99 tmp.c

the following Compilation warning is produced with gcc
const_ptr.c: In function `main':
const_ptr.c:27: warning: passing arg 1 of `myfn' from incompatible
pointer type

If I remove the const qualifier in myfn( ), the program compiles with
gcc without any warning.

However with VC++ 2005, there is no compilation warning with the
original program ie even when the const qualifier is present.

QUESTION:
-----------------
Why is the warning generated with gcc ?

This question arises because of the following reason.
We can pass a char[] to a function which receives it as const char*.
Here there is no compilation warning reported. But when a char *a[] is
passed, why can't it be received as "const char ** " ?

Feb 19 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Feb 19, 7:11 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.comwrote:
Consider the following program:

#include <stdio.h>

void myfn(const int **a)
{
static int i, j, k;

a[0] = &i;
a[1] = &j;
a[2] = &k;

return;

}

int main(void)
{
int *a[3];
int x, y, z;

a[0] = &x;
a[1] = &y;
a[2] = &z;

x = 10;
y = 20;
z = 30;

myfn(a);

return 0;

}

Suppose the program name is tmp.c

When this program is compiled with gcc under Redhat Enerprise Linux,
with the command
gcc -std=c99 tmp.c

the following Compilation warning is produced with gcc
const_ptr.c: In function `main':
const_ptr.c:27: warning: passing arg 1 of `myfn' from incompatible
pointer type

If I remove the const qualifier in myfn( ), the program compiles with
gcc without any warning.

However with VC++ 2005, there is no compilation warning with the
original program ie even when the const qualifier is present.

QUESTION:
-----------------
Why is the warning generated with gcc ?

This question arises because of the following reason.
We can pass a char[] to a function which receives it as const char*.
Here there is no compilation warning reported. But when a char *a[] is
passed, why can't it be received as "const char ** " ?
I think the problem is if you are using "const int **", you are
telling the compiler that you are passing a pointer of pointer
pointing to a constant integer value. But in your main, "a" is not
pointing to a const value. This will have problem.

Feb 19 '07 #2

P: n/a
su**************@yahoo.com, India wrote:
...
void myfn(const int **a)
{
...
}

int main(void)
{
int *a[3];
...
myfn(a);
...
}

...
the following Compilation warning is produced with gcc
const_ptr.c: In function `main':
const_ptr.c:27: warning: passing arg 1 of `myfn' from incompatible
pointer type

If I remove the const qualifier in myfn( ), the program compiles with
gcc without any warning.
...
Argument 'a' in the function call has type 'int*[3]' which in this particular
context decays to type 'int**'. The corresponding parameter has type 'const
int**', which means that in this case you are trying to convert a 'int**' value
to 'const int**' type implicitly. This is not legal in C language. 'int*' can be
implicitly converted to 'const int*', but 'int**' cannot be implicitly converted
to 'const int**'. It the latter conversion were legal, it would let one to
circumvent const-correctness rules without an explicit cast. See the following
FAQ item for more detail

http://www.parashift.com/c++-faq-lit...html#faq-18.17

(This is a C++ FAQ entry, but the principle it illustrates applies immediately
to C as well)

--
Best regards,
Andrey Tarasevich
Feb 21 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.