Improvement: better diagnostics for undefined behavior

[pmor13]

Compiling this code:

void foo(void)
{
    struct x* y;
    *y;
}

with -O3 -std=c11 -pedantic -Wall -Wextra leads to:

<source>:4:5: error: incomplete type 'struct x' where a complete type is required
    4 |     *y;

For people who learned C11 by reading C11 this diagnostic may be confusing because C11 does not require the operand of the unary * operator to be pointer type, which points to an object of a complete type.

Expected diagnostics:

<source>:4:5: error: lvalue conversion: lvalue has an incomplete type
    4 |     *y;

@AaronBallman

[AaronBallman]

I'm not convinced the new diagnostic is better than the old one; the wording is saying the same thing for the same reasons. A complete type is required because *y dereferences a pointer and then lvalue conversion happens which requires the object to be a complete type. So an incomplete type is showing up where a complete type is required, and it's doing so because of lvalue conversion. However, I don't think average users really should have to think in terms of "lvalue" and "rvalue" as those are more language lawyer-type terms.

[pmor13]

@AaronBallman A complete type is not required because the C11 does not require it. (Therefore, people who learned C11 by reading C11 this "is required" diagnostic may be confusing.) Lvalue conversion does not require the object to be a complete type.

C11, 6.3.2.1p2:

If the lvalue has an incomplete type and does not have array type, the behavior is undefined.

The code above triggers UB.

The "is required" diagnostic may be interpreted as "is required by an implementation". (So, I'm OK with that.)

[AaronBallman]

@AaronBallman A complete type is not required because the C11 does not require it. (Therefore, people who learned C11 by reading C11 this "is required" diagnostic may be confusing.) Lvalue conversion does not require the object to be a complete type.

C11, 6.3.2.1p2:

If the lvalue has an incomplete type and does not have array type, the behavior is undefined.

The code above triggers UB.

The "is required" diagnostic may be interpreted as "is required by an implementation". (So, I'm OK with that.)

A complete type is required in order to have a well-defined program, so yes, lvalue conversion does require the type to be complete. Also, I don't think we should worry about people who learned C11 by reading the standard, that's not the average user we're optimizing diagnostic wording for. Therefore, I think this issue should be closed as Won't Fix; the existing diagnostic wording is correct and explains the issue, the proposed wording doesn't help the programmer to understand what's wrong with their code.

Also worth noting that while this was UB in older standards mode, it's a constraint violation in C2y (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3481.pdf)

[pmor13]

Thanks for n3481.pdf. (I wondered "why UB rather than a constraint?", so the n3481.pdf fixes it.)

OK for "Won't Fix".