Dereferencing void pointer shouldn't be rejected

[Halalaluyafail3]

Clang rejects dereferencing a void pointer, for example:

*(void*)0;

I don't see any constraints that this would violate so this should be OK I think, at least as long as the expression goes unevaluated. GCC accepts this (with a warning by default), MSVC rejects it but even in contexts that should make sense like &*(void*)0.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Halalaluyafail3)

Clang rejects dereferencing a void pointer, for example: ```c *(void*)0; ``` I don't see any constraints that this would violate so this should be OK I think, at least as long as the expression goes unevaluated. GCC accepts this (with a warning by default), MSVC rejects it but even in contexts that should make sense like `&*(void*)0`.

[frederick-vs-ja]

C++ clearly rejects this, see [expr.unary.op]/1.

The situation in C is somehow weird. Let's talk about a "possibly more well-defined" example instead:

int main(void)
{
    int i;
    *(void*)&i;
}

Quoting from N3220:

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⁵⁵⁾; if an lvalue does not designate an object when it is evaluated, the behavior is undefined.

(Note that cv void are object types in C.)

6.5.4.2 Address and indirection operators

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. 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.¹⁰¹⁾

In the example above, the void* pointer does point to the i object, so the situation doesn't fall into UB by omission, and the result of dereferencing is an lvalue designating the object the i object. It's also specified that the operand has type “pointer to void”, so the result has type void. So "lvalue of type void" is formed here, which conflicts with 6.3.2.1/1.

#60243 is related, although this issue is not its exact duplicate. CC @AaronBallman.

[Halalaluyafail3]

It's also specified that the operand has type “pointer to void”, so the result has type void. So "lvalue of type void" is formed here, which conflicts with 6.3.2.1/1.

This wording hasn't been changed since C89, so I think it was written with the assumption that void was not an object type (which it wasn't prior to C11). Another example of this happening is:

If the expression that denotes the called function has type pointer to function returning an object
type, the function call expression has the same type as that object type, and has the value determined
as specified in 6.8.7.5. Otherwise, the function call has type void.

from 6.5.3.3 "Function calls" Paragraph 5, the current definition of an object type would mean that this last sentence would be meaningless.

[AaronBallman]

I believe it's UB.

C23 6.5.4.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.

The result of *(void *) is supposed to be "an lvalue designating the object". However, 6.3.2.1p1 says:

An lvalue is an expression (with an object type other than void) that potentially designates an object; if an lvalue does not designate an object when it is evaluated, the behavior is undefined. ...

So an object type other than void is an lvalue, but in this case we have a void object so it cannot be "an lvalue designating the object". So I think we hit UB by omission and our current warning diagnostic is correct.

[cor3ntin]

Relevant for C++ https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2875 (as @frederick-vs-ja said, this is UB and very much intentionally so)

[Halalaluyafail3]

This is another case worth considering:

*(const void*)0;

Clang currently rejects this too, but unlike the previous example const void can be the type of an lvalue. In fact clang even accepts this as per DR 12:

extern const void v;
&v;

[Halalaluyafail3]

Also DR 12 specifically mentions this:

void*p;
&*p;

To say that &*p is not valid because *p is not an lvalue. If *p was meant to be invalid on its own then surely they would mention that. Hence, I think it's intended for it to be valid.