Casting int'** to 'const int * const * const' dosn't work, why?

[Jonas.Holmsten]

Hello

I'm porting some C++ stuff to C and having problem to get it through
gcc.
Here is a condensed version of the problem:

void foo(const int * const * const ptr)
{}

main()
{
int i = 5;
int *ptr = &i;

foo(&ptr);
}

The warning is:
warning: passing arg 1 of `foo' from incompatible pointer type.

Can't C implicit cast a int** to 'const int * const * const'? (it
works fine in C++)

/Jonas

 

[Ben Bacarisse]

Hello

I'm porting some C++ stuff to C and having problem to get it through
gcc.
Here is a condensed version of the problem:

void foo(const int * const * const ptr)
{}

main()
{
int i = 5;
int *ptr = &i;

foo(&ptr);
}

The warning is:
warning: passing arg 1 of `foo' from incompatible pointer type.

Can't C implicit cast a int** to 'const int * const * const'? (it
works fine in C++)

Let me pick a nit. C has no "implicit casts". A cast is an operator
and is always explicit in the code.

Short answer your question: no. C does not consider "int **" and
"const int * const * const" to be compatible types. You need a cast:

foo((const int **)&ptr);

The rules for parameter passing derive from the rules for assignment
(in case you want to look up the standard) and they allow qualifiers to
be added at only one level of indirection. So passing a "T *"
argument to a "const T *" pointer is fine, but passing "T **" where
"const T **" is expected is not.

 

[Tor Rustad]

Hello

I'm porting some C++ stuff to C and having problem to get it through
gcc.
Here is a condensed version of the problem:

void foo(const int * const * const ptr)
{}

main()
{
int i = 5;
int *ptr = &i;

foo(&ptr);
}

The warning is:
warning: passing arg 1 of `foo' from incompatible pointer type.

Can't C implicit cast a int** to 'const int * const * const'? (it
works fine in C++)

This is really a question for Chris Torek...

Here is a simpler example:

$ cat const_cast.c
int main(void)
{
int **ppi;
const int * const *pcpci;

pcpci = ppi;


return 0;
}
$ cc -ansi -pedantic -Wall -W const_cast.c
const_cast.c: In function âmainâ:
const_cast.c:7: warning: assignment from incompatible pointer type

which requires a diagnostic in C (but perhaps not in C++, since no
const'ness is lost).

In C, two types are compatible if they are the same type (not only if).
A type qualifier (like const), change the type. When it comes to pointer
types, they are compatible, if they point to compatible types.

 

[Tor Rustad]

Tor Rustad wrote:
... snip ...

No. const objects must be initialized at declaration time.

Before posting, I even checked that 'pcpci' was a pointer (to const
pointer to const int).

What am I missing exactly?

 

[Ben Bacarisse]

No. const objects must be initialized at declaration time.

I may be missing your point, but pcpci is not a const object.

 

[Peter Nilsson]

Hello

I'm porting some C++ stuff to C
and having problem to get it through gcc.
Here is a condensed version of the problem:

void foo(const int * const * const ptr)
{}

The last const is redundant. Don't cloud the issue.

main()

Prefer explicit int...

int main(void)

{
int i = 5;
int *ptr = &i;

Replace this with...

const *ptr = &i;

....and it should work.

foo(&ptr);
}

The warning is:
warning: passing arg 1 of `foo' from incompatible pointer type.

Can't C implicit cast a int** to 'const int * const * const'?

You mean can't C implicitly _convert_. The conversion is well
defined, however the absense of a cast requires a diagnostic
for a constraint violation.

I recall a thread (I may even have started it!) in csc some
time ago where contributing committee members said that once
a constraint was violated, the code invokes undefined behaviour,
even though the behaviour is otherwise defined, and even if
an implementation succeeds to translate the code.

(it works fine in C++)

At the end of the day, C is not C++.

 

[Ben Bacarisse]

This is really a question for Chris Torek...

Here is a simpler example:

$ cat const_cast.c
int main(void)
{
int **ppi;
const int * const *pcpci;

pcpci = ppi;


return 0;
}
$ cc -ansi -pedantic -Wall -W const_cast.c
const_cast.c: In function âmainâ:
const_cast.c:7: warning: assignment from incompatible pointer type

which requires a diagnostic in C (but perhaps not in C++, since no
const'ness is lost).

In C, two types are compatible if they are the same type (not only
if). A type qualifier (like const), change the type. When it comes to
pointer types, they are compatible, if they point to compatible
types.

If it were that simple, then assigning a char * to a const char *
would also be a constraint violation and it is not.

6.5.16.1 Simple assignment
Says that (amongst other things):

-- 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;

So assignment (and, by extension, parameter passing) is allowed to "add
qualifiers" to the pointed-to type (but not to the type pointed-to by
the pointed-to type).

As far as I can tell, this rule is somewhat arbitrary and is intended,
presumably, to simplify the compiler's job. It (or something like it)
is required because without it a constraint-free program could modify
a const object[1] but at least one other language took the view that
all "safe" assignments would be allowed. Thus the OP's original
example (with const at every level) causes not a peep from a C++
compiler.

Does anyone know the reason C chose this safe but restrictive rule?
Does it significantly simplify the compiler?

[1] Like this:

char *p;
const char foo = 'F';
const char **cp = &p; /* Innocent at first glance */
*cp = &foo;
*p = 'B'; /* Pow! */

This (correctly) raises the alarm from both C and C++ compiler, but
changing the key line to:

const char *const *cp = &p; /* Entirely safe. */

causes C++ to complain only at the now obviously illegal line following
where a now const object is being modified. Both this new line and
the following one are constraint violations as far as C is concerned.

 

[Tor Rustad]

Ben Bacarisse wrote:

If it were that simple, then assigning a char * to a const char *
would also be a constraint violation and it is not.

<snip>

That was an excellent clarification, great post Ben!

 

[Tor Rustad]

CBFalconer wrote:

[...]

Before posting, I even checked that 'pcpci' was a pointer (to const
pointer to const int).

What am I missing exactly?

You can't write to const objects.

I know that, and didn't do such a thing.

 

[David Thompson]

On Sat, 02 Jun 2007 05:47:06 +0100, Ben Bacarisse

So assignment (and, by extension, parameter passing) is allowed to "add
qualifiers" to the pointed-to type (but not to the type pointed-to by
the pointed-to type).

As far as I can tell, this rule is somewhat arbitrary and is intended,
presumably, to simplify the compiler's job. It (or something like it)
is required because without it a constraint-free program could modify
a const object[1] but at least one other language took the view that
all "safe" assignments would be allowed. Thus the OP's original
example (with const at every level) causes not a peep from a C++
compiler.

Does anyone know the reason C chose this safe but restrictive rule?
Does it significantly simplify the compiler?

In ~1989 when const was added they chose they simplest rule that was
obviously safe. It may or may not have significantly simplified the
compiler, but it did significantly simplify programmers', and standard
writers' and voters', rapid understanding of this new feature.

With several years of experience, C++ could choose the somewhat more
flexible rule of adding qualification at all or multiple inner levels.

C99 probably could have followed C++(98) but didn't. I don't know if
it was proposed, although they did have plently of other work to do.
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Ben Bacarisse]

On Sat, 02 Jun 2007 05:47:06 +0100, Ben Bacarisse

In ~1989 when const was added they chose they simplest rule that was
obviously safe. It may or may not have significantly simplified the
compiler, but it did significantly simplify programmers', and standard
writers' and voters', rapid understanding of this new feature.

Ah, yes. I was ignoring the value a simple rule would have for
understanding and acceptance.

 

[lawrence.jones]

C99 probably could have followed C++(98) but didn't. I don't know if
it was proposed, although they did have plently of other work to do.

It was certainly considered, but there are substantial (and sometimes
quite subtle) differences between the way the C and C++ standards
describe their respective languages such that the rules couldn't just be
transplanted intact, but would have to be rewritten. And C99 added the
restrict qualifier that isn't covered by the existing C++ rules and
behaves quite differently from const and volatile. All in all, it would
have been a good bit of work and no one volunteered to undertake it.

I'm reasonably sure the committee would be happy to consider relaxed
conversion rules if someone were to work out the details and propose
them.

-Larry Jones

If I get a bad grade, it'll be YOUR fault for not doing the work for me!
-- Calvin