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".

[pmor13]

@AaronBallman Does lvalue conversion imply lvalue evaluation?

Reason for the question: n3481.pdf has:

During lvalue conversion, an lvalue shall not have an incomplete type.

while C2y (n3299.pdf) has:

if an lvalue does not designate an object when it is evaluated, the behavior is undefined.

So, if an lvalue conversion does imply lvalue evaluation, then there is a contradiction ("behavior is undefined" contradicts with "shall not have an incomplete type").

[AaronBallman]

I believe lvalue conversion does imply evaluation. A paragraph later, it says:

Except when it is the operand of the sizeof operator, or the typeof operators, the unary & operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator, an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion.

The implied evaluation comes from "converted to the value stored in the designated object" which means we need to evaluate to get the value.

But this isn't a contradiction; N3481 struck the wording making it UB and inserted wording making it a constraint violation.

[pmor13]

Re: "we need to evaluate to get the value": OK.

n3481.pdf says (emphapsis added):

During lvalue conversion, an lvalue shall not have an incomplete type.

However, this "during" also includes lvalue evaluation.

Now consider lvalue conversion where lvalue does not designate an object.

At the same time:

• the behavior is defined, because it is a constraint violation ("during lvalue conversion, an lvalue shall not have an incomplete type")
• the behavior is undefined, because "lvalue does not designate an object when it is evaluated"

Hence, the contradiction.

What do I miss?

N.B. I may think that During needs to be replaced with "Before" (so the constraint is violated before an lvalue is evaluated). Any comments?