C compiler: missing diagnostics "dereferencing 'void *' pointer"

[pmor13]

Sample code (t0.c):

void f(void* p)
{
	*p;
}

Invocation:

$ clang t0.c -std=c11 -pedantic -Wall -Wextra -c

Expected diagnostics:

dereferencing 'void *' pointer

Actual diagnostics:

<nothing>

Version:

13.0.0

C11, 6.5.3.2 Address and indirection operators, Semantics, 4:

The unary * operator denotes indirection. If the operand points to a function, the result is a function
designator; if it points to an object, the result is an lvalue designating the object.

C11, 6.3.2.1 Lvalues, arrays, and function designators, 1:

An lvalue is an expression (with an object type other than void) that potentially designates an object; ...

[llvmbot]

@llvm/issue-subscribers-c

[pmor13]

Update. Actually for the unary * operator there is no constraint "the operand shall not be a pointer to void" (or similar). One of the reasons is to support &*p. Hence, it seems that this issue is "not a problem".

[AaronBallman]

There's no constraint violation (no lvalue to rvalue conversion happening because it's a discarded statement), but at the same time, it would be appropriate for us to warn in this case as the code is... odd. If we wanted to be particularly pedantic and not warn on &*ptr, that would be fine, but even there, I would be okay warning because writing that code is more likely to be a mistake than an intentional piece of code.

So I don't think this is a bug, but I think it's a very reasonable feature request.

[pmor13]

@junaire Any interest / motivation / time to take care of this issue?

Note: here is another possible diagnostics:

the result of the unary * operator is not an lvalue

[AaronBallman]

FWIW, I looked into this a few weeks back and it seems possible to do but is a bit more complicated because we need to allow &*whatever even when whatever is a void *.

I eventually convinced myself that the comment we have in our source code about *void_ptr being "well-defined" is wrong. The wording in the standard makes it sound like it's well defined, but when you read a bit more carefully you see that it's UB by omission.

C2x 6.5.3.2p4: The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type "pointer to type", the result has type "type". If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.

"if it points to an object" is satisfied because void is an incomplete object type, specifically (6.2.5p23). However, there is no way to form an lvalue designating an object of an incomplete type due to 6.3.2.1p1 ("An lvalue is an expression (with an object type other than void) that potentially designates an object;68) if an lvalue does not designate an object when it is evaluated, the behavior is undefined."). So the standard doesn't define what it means to form an lvalue to void, thus it's UB by omission.

We have a C++ extension to allow dereferencing a void pointer, and I think our C code should be roughly the same except for the &* case.

[junaire]

@junaire Any interest / motivation / time to take care of this issue?

Note: here is another possible diagnostics:

the result of the unary * operator is not an lvalue

Sure, I can take it.

I eventually convinced myself that the comment we have in our source code about *void_ptr being "well-defined" is wrong. The wording in the standard makes it sound like it's well defined, but when you read a bit more carefully you see that it's UB by omission.

Do you mean this?
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaExpr.cpp#L14523-L14534

[AaronBallman]

Do you mean this?
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaExpr.cpp#L14523-L14534

Yup! That's exactly what I meant. The mildly tricky bit is, the caller of this function has information about whether the * is the subject of a & operator or not, and we need to thread that information down to there to decide whether to issue the extension warning or not. &*ptr is well-defined even if &(*ptr) is UB (isn't C great?).

[junaire]

Do you mean this?
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaExpr.cpp#L14523-L14534

Yup! That's exactly what I meant. The mildly tricky bit is, the caller of this function has information about whether the * is the subject of a & operator or not, and we need to thread that information down to there to decide whether to issue the extension warning or not. &*ptr is well-defined even if &(*ptr) is UB (isn't C great?).

Hmmm OK. I noticed that GCC can't deal with this correctly as well. But my concern is that do we have to be that "strict"? Following the standard definitely should be the only duty of the compiler, but I do think that giving a helpful diagnostic to the users is more important, instead of trying to take care of every corner of the language.

IMHO, we should always warn when trying to dereference void pointers, as it doesn't really make too much sense. (at least in C mode)

&*ptr is well-defined even if &(*ptr) is UB

We could be more specific, but I feel like it doesn't really help the users. What's more, we may have to pass some crazy flags or enums to add extra complexity to Clang just for this really corner but "unharmful" case. I just feel like not worth it.