https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
Bug ID: 120009
Summary: RFE: idea: void (dummy) objects (really...)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
In the case of configurable code, it sometimes happens that a variable,
structure member or function argument becomes pointless. At this point, the
only ways around that are to either waste resources carrying a pointless value
around (which need to be initialized at every call site, or cleared in the case
of a security-sensitive structure, etc.) or using some very very ugly macros.
The code in newlib to support threading both with and without TLS support is a
great example.
One way that might be handled would be to allow for an object to explicitly be
declared "void" (possibly differently named, see below.) This would have the
following semantics:
1. A function argument that is void does not take up a register or memory
position in the ABI.
2. A structure member which is void occupies no space in the structure.
3. It is not permitted to take the read, write, or take the address of a void
object (alternatively taking the address could be defined as always being NULL,
see below); the sole exceptions being when assigning to another object of type
void (which is of course a null operation):
a. "foo = bar;" where both foo and bar are void;
b. "return foo;" in a function of type void;
c. Passing one into a function argument of type void;
4. sizeof(void) == 0
There are, unfortunately, a couple of potential conflicts with using the
existing "void" type, which may call for using a different keyword;
specifically:
a. "void" pointers being generic pointers. Another type, say "dummy_t" could
permit the & operator on a dummy_t object; a dummy_t * could itself be a dummy
object, either non-convertible to any other pointer type (including void *) or
always convert to a NULL pointer.
b. The existing use of (void) as a function prototype would end up defining a
single unnamed argument of type void. This isn't *inherently* a problem, but
would have a couple of implications (not necessarily fundamental problems), the
most important being the potential for conflict with C++ overloading of
functions, which presumably would want to distinguish an empty argument list
from one containing a dummy argument. This could be resolved by distinguishing
the literal keyword "void" by itself from the type resulting from a typedef
void ...; (which is how this would be used in practice anyway) or with a
variable name included.
c. Potential issues when a structure ends up completely empty?
