Void questions

[Tim Rentsch]

On 2/2/2010 4:34 AM, Francis Moreau wrote:
Hello,

I have some stupids questions about void type and pointer to void.

Actually I've always known the answers but I wanted to find the
revelant parts in the C specs and fails.

The first one is about dereferencing a void pointer. It's just
forbidden but when reading 6.5.3.2 about indirection operators, I
can't find anything that states it.

6.5.3.2p4 specifies what happens when dereferencing a
pointer "to a function" or "to an object." A void* obviously
can't do the first. What you're probably missing is that it
also can't do the second, because of 6.2.5p1: "[...] Types are
partitioned into object types [...], function types [...], and
incomplete types [...]" A void* is a pointer to an incomplete
type, not a pointer to an object type, so the language of
6.5.3.2p4 doesn't apply.

I believe this interpretation is a misreading. The Standard means
what it says, if the pointer "points to an object" is talking about
where the pointer points, not what type of pointer it is.

I know that my English sucks (as someone pointed out) but I'm not
convinced about what you stated:

Here's the beginning of 6.2.5p1:

The meaning of a value stored in an object or returned by a
function is determined by the type of the expression used to
access it. Types are partitioned into...

Why is the spec so hard to read ?!

[snip]

I'm not sure if the question posed is meant as rhetorical or
to be directed to me, but in either case I'd like to respond
to the "not convinced" statement.

First here's the rest of that last sentence from 6.2.5p1:

Types are partitioned into object types (types that fully
describe objects), function types (types that describe
functions), and incomplete types (types that describe objects
but lack information needed to determine their sizes).

Note that incomplete types still describe objects.

Talking about pointers, in the Standard commonly uses the phrases
"pointer to [X]" and "points to [Y]", for different X's and Y's. The
phrase "pointer to [X]" sometimes is talking about the type of what's
being pointed to, and sometimes is talking about what is being pointed
to rather than its type. As far as I am aware (having checked through
scads of references), the two kinds of usage are consistent when
talking about "objects". More specifically, if "object" is used as a
noun, the phrase is talking about _what's_ being pointed at, but if
the phrase is talking about the _type_ of what's being pointed at,
"object" will be used as an adjective (modifying "type").

For "points to ...", as far as I am aware this phrase (when discussing
a pointer) is always talking about _what_ the pointer is pointing
at, not what type of thing it's pointing at. There is one case
where "points to ..." is talking about the type of the thing pointed
to, but the item under discussion in that case is a type name (T), not
a pointer.

Of course, I may have missed some uses of these phrases; still I did
look at quite a few. If you find any that don't agree with the above
descriptions, I definitely would like to hear about them.

Also, notice a sentence in the same section (specifically in 6.5.3.2p1
(talking about the unary & operator):

The operand of the unary & operator shall be either a function
designator, the result of a [] or unary * operator, or an lvalue
that designates an object that is not a bit-field and is not
declared with the register storage-class specifier.

Notice the "an object" phrase. This constraint is talking about
what is being designated, not about whether the operand has object type
or not. We know that because this code

int some_array[];
int (*some_array_address)[] = &some_array;

is legal, and the operand 'some_array' has incomplete type. So
that is another confirming instance when "an object", used as a
noun rather than an adjective modifying "type", means 'what is
being referred to' and not 'what kind of type it has'.

Is that more convincing now?

 

[Richard Tobin]

Types are partitioned into object types (types that fully
describe objects), function types (types that describe
functions), and incomplete types (types that describe objects
but lack information needed to determine their sizes).

Note the last part. Incomplete types still describe objects. Pointers
to incomplete types still point to objects, it just isn't known how
big the objects are.

Are you saying that because void is an incomplete type, void *
pointers point to objects of unknown size? They certainly doesn't
point to objects of type void, because there aren't any.

-- Richard

 

[Tim Rentsch]

Are you saying that because void is an incomplete type, void *
pointers point to objects of unknown size?
Yes.

They certainly doesn't
point to objects of type void, because there aren't any.

There aren't any objects of type (int[]) either, but
pointers to incomplete arrays still point to objects.

The type (void) is unusual in that it means, in a sense,
"any type" or "some undetermined type". It's also unusual
in that, used by itself (ie, not as part of a pointer type)
it means something different than it does in conjunction
with pointerness -- namely, (void) approximately means
"valueless" or "disregard the value, if any". This last
sense resembles the "any type" of a target of (void *),
because any value may converted to a "value" of type (void).
So in some sense all objects are objects of type (void),
in addition to whatever other type(s) they may be.

 

[Curtis Dyer]

(I don't think "-pedantic" by itself is sufficient to cause gcc
to become a conforming C compiler.)

You are right. Using the `-ansi' or `-std=...' switches are needed
to disable the GNU extensions.