Authors: Jay Ghiron
Date: 2026-02-05
Submitted against: C23
Status: Open
Cross-references: 0012, 0106
The standard does not seem to reflect the intent in the responses to DR 12 and DR 106. Specifically this is the result of discussion in LLVM issue 112121.
Being able to dereference void pointers is useful in making generic
code, specifically when doing typeof(*_Generic(...)) to select
between multiple types. Returning a void pointer here causes the type
to be void. Same with pointers to qualified void, _Atomic void*, and pointers to qualified atomic void.
Given the declaration void*p; is the expression *p valid?
If *p is valid, is it an lvalue or a void expression? The standard
as written appears to say lvalue, even though that contradicts the
definition of lvalues and the intent expressed in DR 12
and DR 106: "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." (C23 6.5.4.3).
If *p is valid and it is a void expression, when does evaluating the
expression produce defined behavior or undefined behavior? That is,
what does it mean for a pointer to void to be invalid? Presumably if
p is indeterminate the behavior is undefined.
If *p is valid and it is an lvalue, would it therefore be valid to
do &*p directly contradicting DR 12?
Is the declaration extern void v; valid?
If that declaration is valid, is an expression naming v valid?
If that declaration is valid and an expression naming v is valid, is
such an expression an lvalue or a void expression? The standard as
written appears to say lvalue, even though that contradicts the
definition of lvalues and the intent expressed in DR 12:
"An identifier primary expression designating an object is an lvalue."
(C23 6.5.2).
If that declaration is valid and an expression naming v is valid and
is an lvalue, would it therefore be valid to do &v directly
contradicting DR 12?
Are qualified versions of void, the type _Atomic void, and
qualified versions of _Atomic void regular incomplete types with no
special semantics in expressions? That seems to be the intent in DR
12, but DR 106 appears to also treat them
as void expressions too.