Question

I have this opaque type type_t and a function prototype like foo(type_t *t) and callee:

int bar(void)
{
    type_t t;

    foo(&t);

    return 0;
}

I wanted to change function prototype from foo(type_t *t) to foo(const type_t *t).

Unfortunately type_t is defined as an array, for example, typedef char type_t[16]) …
So calling function foo with &t argument makes compiler generate warning.

In the first place, foo function should have a prototype such as foo(type_t t) and be called with foo(t). In this case, I was hoping that array decay to pointer rule would also allow foo(&t), but it doesn’t apply for & operator. Such would probably work if foo was written foo(void *t)

note: you can skip the detailed examples, see the end

So I wrote this little test program to reproduce warning/errors https://gist.github.com/2644970

GCC version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) is producing those warnings:

array.c: In function ‘test_array_pointer’:
array.c:36: warning: return makes integer from pointer without a cast
array.c: In function ‘test_const_array_pointer’:
array.c:59: warning: return makes integer from pointer without a cast
array.c: In function ‘main’:
array.c:132: warning: passing argument 1 of ‘test_array_pointer’ from incompatible pointer type
array.c:18: note: expected ‘uint8_t (*)[16]’ but argument is of type ‘uint8_t *’
array.c:134: warning: passing argument 1 of ‘test_const_array_pointer’ from incompatible pointer type
array.c:41: note: expected ‘const uint8_t (*)[16]’ but argument is of type ‘uint8_t (*)[16]’
array.c:135: warning: passing argument 1 of ‘test_const_array_pointer’ from incompatible pointer type
array.c:41: note: expected ‘const uint8_t (*)[16]’ but argument is of type ‘uint8_t *’
array.c:137: warning: passing argument 1 of ‘test_array’ from incompatible pointer type
array.c:64: note: expected ‘uint8_t *’ but argument is of type ‘uint8_t (*)[16]’
array.c:140: warning: passing argument 1 of ‘test_const_array’ from incompatible pointer type
array.c:82: note: expected ‘const uint8_t *’ but argument is of type ‘uint8_t (*)[16]’
array.c:143: warning: passing argument 1 of ‘test_const_pointer’ from incompatible pointer type
array.c:100: note: expected ‘const uint8_t *’ but argument is of type ‘uint8_t (*)[16]’

While LLVM/Clang version 1.1 (branches/release_27) is producing those:

array.c:36:10: warning: incompatible pointer to integer conversion returning 'array_t' (aka 'uint8_t [16]'), expected 'uintptr_t' (aka 'unsigned int') [-pedantic]
  return a[0]; /* warning: return makes integer from pointer without a cast */
         ^~~~
array.c:59:10: warning: incompatible pointer to integer conversion returning 'array_t const' (aka 'uint8_t const[16]'), expected 'uintptr_t' (aka 'unsigned int') [-pedantic]
  return a[0]; /* warning: return makes integer from pointer without a cast */
     ^~~~
array.c:132:3: warning: incompatible pointer types passing 'array_t' (aka 'uint8_t [16]'), expected 'array_t *' [-pedantic]
  TEST(array_pointer, a);
  ^~~~~~~~~~~~~~~~~~~~~~
array.c:132:23: note: instantiated from:
  TEST(array_pointer, a);
                      ^
array.c:134:3: warning: incompatible pointer types passing 'array_t *', expected 'array_t const *' [-pedantic]
  TEST(const_array_pointer, &a);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
array.c:134:29: note: instantiated from:
  TEST(const_array_pointer, &a);
                            ^~
array.c:135:3: warning: incompatible pointer types passing 'array_t' (aka 'uint8_t [16]'), expected 'array_t const *' [-pedantic]
  TEST(const_array_pointer, a);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
array.c:135:29: note: instantiated from:
  TEST(const_array_pointer, a);
                            ^
array.c:137:3: warning: incompatible pointer types passing 'array_t *', expected 'uint8_t *' [-pedantic]
  TEST(array, &a);
  ^~~~~~~~~~~~~~~
array.c:137:15: note: instantiated from:
  TEST(array, &a);
              ^~
array.c:140:3: warning: incompatible pointer types passing 'array_t *', expected 'uint8_t const *' [-pedantic]
  TEST(const_array, &a);
  ^~~~~~~~~~~~~~~~~~~~~
array.c:140:21: note: instantiated from:
  TEST(const_array, &a);
                    ^~
array.c:143:3: warning: incompatible pointer types passing 'array_t *', expected 'uint8_t const *' [-pedantic]
  TEST(const_pointer, &a);
  ^~~~~~~~~~~~~~~~~~~~~~~
array.c:143:23: note: instantiated from:
  TEST(const_pointer, &a);
                      ^~
8 diagnostics generated.

note: reduced version

See this last example:

typedef char array_t[16];

static int
test_const_array_pointer(const array_t *a)
{
    return 0;
}

int
main(void)
{
    array_t a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf };
    const array_t b = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf };

    test_const_array_pointer(&a); /* warning: passing argument 1 of ‘test_const_array_pointer’ from incompatible pointer type
                                     note: expected ‘const char (*)[16]’ but argument is of type ‘char (*)[16]’ */

    test_const_array_pointer(a); /* warning: passing argument 1 of ‘test_const_array_pointer’ from incompatible pointer type
                                     note: expected ‘const char (*)[16]’ but argument is of type ‘char *’ */

    test_const_array_pointer(&b); /* OK */

    test_const_array_pointer(b); /* warning: passing argument 1 of ‘test_const_array_pointer’ from incompatible pointer type
                                    note: expected ‘const char (*)[16]’ but argument is of type ‘const char *’ */

    return 0;
}

I thought &a would be equivalent to &b. For example it’s not necessary when a function has a prototype foo(const char *) to give const char *, e.g. passing char * is accepted.

So my question is why an argument such as const array_t * requires a pointer to a const array ? (pointers to C11 draft section would be appreciated).

Answer 1

This is an effect of the fact that arrays are not first-class types in C. Because they aren’t first-class types, it doesn’t really make any sense to have type qualifiers (such as const) on arrays — as you can’t assign to or use arrays directly, the qualifier would have no effect. So when you try to apply a qualifier to an array, it is silently moved to the array elements. As a result, when you say const array_t *, you’re NOT getting a pointer to a const array of chars, you’re getting a pointer to an array of const chars. A subtle but important distinction.

This reveals why test_const_array_pointer(&a) fails. The exact rule for matching arguments in C is that they are treated as assignments to the parameter variable and follow the rule for assignments. The relevant constraint from 6.5.16.1 in the spec is:

the left operand has atomic, qualified, or unqualified pointer type, and (considering
the type the left operand would have after lvalue conversion) 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;

In this case, the left operand is a pointer to an array of const chars, while the right operand is a pointer to an array of chars. Both are pointers, but as “array of chars” and
“array of const chars” are not compatible types, it fails.

This ends up to being similar to the question “Why can’t I pass a char ** to a function that expects a const char * const *“. In both cases, since the function can’t modify the thing the parameter points to directly (because its also const in the double pointer case, because its an array and arrays can’t be modified directly in your case), it would seem to be non-harmful — there’s no way to silently get rid of a const without an explicit cast. The only issue is that it wasn’t considered by the standards committee and/or they didn’t choose to write the matching rules such that it would be allowed.