Is &*p valid C, given that p is a pointer to an incomplete type?

Question

Is the following example a valid complete translation unit in C?

struct foo;

struct foo *bar(struct foo *j)
{
    return &*j;
}

struct foo is an incomplete type, but I cannot find an explicit prohibition of dereferencing an incomplete type in the C standard. In particular, §6.5.3.2 says:

The unary & operator yields the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.

The fact that the result is not an lvalue is not germane - return values need not be. The constraints on the * operator are simply:

The operand of the unary * operator shall have pointer type.

and on the & operator are:

The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier.

Both of which are trivially satisfied here, so the result should be equivalent to just return j;.

However, gcc 4.4.5 does not compile this code. It instead gives the following error:

y.c:5: error: dereferencing pointer to incomplete type

Is this a defect in gcc?

Answer 1

Yes, I think it is a bug. Even lvalues of incomplete types, so *j, seem to be allowed depending on the context:

6.3.2.1 ... An lvalue is an expression with an object type or an incomplete type other than void

Basically this should work as long as you don't do anything with such an lvalue that needs to know about the structure of the struct. So if you don't access the object or ask about its size, this is legal.

Answer 2

The C99 standard (ISO/IEC 9899:1999) describes the behaviour:

§6.5.3.2 Address and indirection operators

The unary & operator returns the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.

This means that &*j is equivalent to j.

However, j is supposed to be a pointer to an object, and it is only a pointer to an incomplete type, as GCC 4.4.5 says.

§6.3.2.3 Pointers

A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.

Note that it distinguishes between an object type and an incomplete type; this occurs frequently in the standard.

So, this observation in the question is incorrect:

Both of which are trivially satisfied here,

The variable j is not a pointer to an object; it is a pointer to an incomplete type, which is not an object.

---

§6.2.5 Types

[...] Types are partitioned into object types (types that fully describe objects), function types (types that describe functions), and incomplete types (types that describe objects but lack information needed to determine their sizes).

Answer 3

Yes. Pointers in C usually have the same size (on some embedded systems, they can be different). This means the compiler can generate the correct assembler code for this even though the type is "unknown".

You can use this approach to completely hide the internal data structure to the outside. Use a typedef to declare a pointer to a structure and only declare the structure in your internal header files (i.e. the files which are not part of your public API).

The reason why gcc 4.4.5 complains is just that: If you use pointers to the incomplete type outside of the implementation, it should work. But the code is part of the implementation and here, you probably want to have the complete type.