something to do with void *

[maadhuu]

hello, this is a piece of code ,which is giving an error.
#include<stdio. h>

int main()
{
int a =10;
void *p = &a;
printf("%d ", *p ); //error....why should it //be an error ?can't the
compiler make out because //of %d that the pointer is supposed to refer to
an integer ?? or is explicit type casting required ??
++p ; //agree that this is an error.
return 0;
}

plssss tell me about the first error.thanx.
ranjan.

[Keith Thompson]

Keith Thompson <ks***@mib.or g> writes:
[...]

Upthread, you mentioned that there have been several DRs confirming
that dereferencing a void* is legal. Do you have pointers to these?

Elsethread, you mentioned DR 106
(<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_106.html>), which
seems to establish that *ptr is valid when ptr is of type void*. It
refers to the C90 standard, but I don't think there was any deliberate
change in this area in C99.

I still think it would be better if the standard said so explicitly.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Dollin]

Robert Gamble wrote:

The result of dereferencing a void pointer is an expression of type
void, good so far.

This so blatantly false I don't know what to make of it; there's likely
some terminological mismatch.

The result of dereferencing a pointer-to-T is a value of type T, not
an expression of any kind.

The *expression* `*p`, where `p` is of type pointer-to-T, is an
expression of type `T`. If this expression is legal and defined, #
its value is an instance of type T, one of T's values.

--
Chris "electric hedgehog" Dollin
predicting self-predictors' predictions is predictably unpredictable.

[Chris Dollin]

Richard Bos wrote:

Chris Dollin <ke**@hpl.hp.co m> wrote:

Robert Gamble wrote:

> Chris Dollin wrote:
>> [1] No, I don't subscribe to the nonsense that `void` is an empty
>> [type. > 6.2.5p19:
> "The void type comprises an empty set of values; it is an incomplete
> type that cannot be completed."
Yes, I know. That's why I said that I didn't subscribe to that
nonsense; because I don't. The view that `void` is an empty type
leads to unfortunate conclusions about the existance of functions
returning void, which are trivially avoided by making void have
a unique instance.

I think you have that backwards. If void had a unique instance, void
functions would return that instance,

Exactly.
which could be used or assigned to something.
Indeed. I see no problem here.
Since void is empty and does _not_ have any values, a void
function returns nothing,

In fact, it can't return, because it can't exist, because it
has no range - if void is an empty type.

--
Chris "electric hedgehog" Dollin
predicting self-predictors' predictions is predictably unpredictable.

[Richard Bos]

Chris Dollin <ke**@hpl.hp.co m> wrote:

Richard Bos wrote:

Chris Dollin <ke**@hpl.hp.co m> wrote:

Robert Gamble wrote:

> Chris Dollin wrote:
>> [1] No, I don't subscribe to the nonsense that `void` is an empty
>> [type.

> 6.2.5p19:
> "The void type comprises an empty set of values; it is an incomplete
> type that cannot be completed."

Yes, I know. That's why I said that I didn't subscribe to that
nonsense; because I don't. The view that `void` is an empty type
leads to unfortunate conclusions about the existance of functions
returning void, which are trivially avoided by making void have
a unique instance.

I think you have that backwards. If void had a unique instance, void
functions would return that instance,

Exactly.

which could be used or assigned to something.

Indeed. I see no problem here.

You don't? So

void func(int a);
int b, c=0;

b=(int)func(c);

doesn't slightly surprise you?

Since void is empty and does _not_ have any values, a void
function returns nothing,

In fact, it can't return, because it can't exist, because it
has no range - if void is an empty type.

I'm sorry, but that's just nonsense. Of course it can return! It just
doesn't return _a value_ to its caller - all it returns is the flow
control.

Richard

[Richard Bos]

Joe Wright <jo********@com cast.net> wrote:

But void is an imaginary type that cannot be completed. Dereferencing
void* is not just Undefined Behavior, it is nonsense.

No, that's too strong, IYAM. Merely dereferencing a void * isn't
undefined behaviour. What causes undefined behaviour is doing anything
with the result.
The Standard clearly states that if p is a void *, then *p is an
expression with type void. What it does _not_ state is what value that
expression has - naturally, since it has none.

Richard

[Chris Dollin]

Robert Gamble wrote:

Chris Dollin wrote:

Robert Gamble wrote:

> Chris Dollin wrote:
>> maadhuu wrote:
>>
>> > hello, this is a piece of code ,which is giving an error.
>> > #include<stdio. h>
>> >
>> > int main()
>> > {
>> > int a =10;
>> > void *p = &a;
>> > printf("%d ", *p ); //error....why should it //be an error
>> > ?can't the
>> > compiler make out because //of %d that the pointer is supposed to
>> > refer to an integer ?? or is explicit type casting required ??
>>
>> *p is illegal because you are not permitted to dereference a void
>> pointer. That you clearly "intended" *p to be an int doesn't permit
>> the compiler to ignore the error.
>
> In this case the printf statement is incorrect, but simply
> dereferencing a valid void pointer is not illegal.
>
>> If *someVoidPointe r *were* legal
>
> Which it is...
I beg to differ. It is not legal in standard C. Your very own quote
below says that `void` is an incomplete type, and incomplete types
cannot be dereferenced when I last looked.

void is an incomplete type, a pointer to void is not. We are talking
about dereferencing a pointer to void.

Sorry; I was tangled. I meant that pointers to incomplete types cannot
be dereferenced, last time I looked.

>> the result would be the unique
>> value of the void type [1], which isn't an int either.
>
> It yields an expression of type void. Not sure what you mean by unique
> value of void type.

Evaluating an expression of type T returns a result which is an
instance of T -- eg, `1+2` is an expression of type `int` who's
result is the value `3`, an instance of `int`.

The unique value of type `void` is the single, unique value which
is of type `void`.

That makes no sense.

Sure it does. Singleton types - types with but a single value - are
perfectly straightforward . COuld you unpack your problem with the above
a bit?

>> [1] No, I don't subscribe to the nonsense that `void` is an empty
>> [type.
>
> Oh, not one of those suckers who blindly subscribes to the Standard?

That's right.

Well there is little hope for you then.

Strange - my experience doesn't bear that out.
You talk about what is "legal
in standard C" and then admit that you don't accept the Standard itself
False. I don't accept that particular technicality in the Standard
as a consistent way of describing the behaviour of `void` and
`pointer-to-void`. I accept that it *is* the way the Standard
describes it.
making your entire argument completely pointless.
Premise false, conclusion does not follow.

> 6.2.5p19:
> "The void type comprises an empty set of values; it is an incomplete
> type that cannot be completed."

Yes, I know. That's why I said that I didn't subscribe to that
nonsense; because I don't.

If you think the Standard is nonsense

See above.
then you have no ground to argue what is or is not Standard complient.

Even if you were right to believe that I thought the /entire/ Standard
was nonsense, I don't see why you would think that I couldn't sensibly
talk about compliance with that Standard.

The view that `void` is an empty type
leads to unfortunate conclusions about the existance of functions
returning void, which are trivially avoided by making void have
a unique instance.

You are going to have to elaborate on this.

My elaboration was broken (I believe repairable, but still broken).
It did not take enough account of side-effects (which, pragmatically,
are the point of calling void functions in the first place) and
also contained an amusing off-by-one error. Witness:

If T is an empty type, then there are no functions of type X -> T
for any X. [Off-by-one: there is /one/ such function; it is
represented by the empty set [of arg-result pairs].]

Of course C functions don't map in such a trivial fashion to
mathematic ones, so the argument was handwavy anyway; I believe,
but without more analysis, that it can be cleanly reconstructed.

--
Chris "electric hedgehog" Dollin
predicting self-predictors' predictions is predictably unpredictable.

[Chris Dollin]

Richard Bos wrote:

Chris Dollin <ke**@hpl.hp.co m> wrote:

Richard Bos wrote:

> I think you have that backwards. If void had a unique instance, void
> functions would return that instance,
Exactly.

> which could be used or assigned to something.

Indeed. I see no problem here.

You don't? So

void func(int a);
int b, c=0;

b=(int)func(c);

doesn't slightly surprise you?

Given the premise - that `void` had a unique value - the only
surprise is that the writer didn't just initialise `b` to `0`
straightaway, rather than casting the result of `func`.

> Since void is empty and does _not_ have any values, a void
> function returns nothing,

In fact, it can't return, because it can't exist, because it
has no range - if void is an empty type.

I'm sorry, but that's just nonsense. Of course it can return! It just
doesn't return _a value_ to its caller

See elsethread for my own retraction of my simplistic analysis,
but note that it's consistent to descibe the function as returning
a value - the empty tuple will do fine.
- all it returns is the flow control.

It's more POV than I had previously thunk.

--
Chris "electric hedgehog" Dollin
predicting self-predictors' predictions is predictably unpredictable.

[Netocrat]

On Tue, 02 Aug 2005 09:18:08 +0100, Chris Dollin wrote:

Robert Gamble wrote:

The result of dereferencing a void pointer is an expression of type
void, good so far.
This so blatantly false I don't know what to make of it; there's likely
some terminological mismatch.

The result of dereferencing a pointer-to-T is a value of type T, not
an expression of any kind.

Can you point out where in the standard it says that? I can't find it, so
I'm assuming that's what you think it should say.
The *expression* `*p`, where `p` is of type pointer-to-T, is an
expression of type `T`.
Agreed.
If this expression is legal and defined, # its
value is an instance of type T, one of T's values.

I can't see where the standard requires that the result is a value. The
quote top of post seems accurate to the wording of 6.5.3.2#4 which doesn't
use the word value to describe the result. Given that a void type can't
have a value, the use of the term "expression " seems appropriate.

As I've argued elsewhere I think that what you're describing should be
mandated by the standard, but I don't think it actually is.

[Netocrat]

On Tue, 02 Aug 2005 04:43:00 +0000, Keith Thompson wrote:

"Robert Gamble" <rg*******@gmai l.com> writes:

Keith Thompson wrote:

<snip discussion on dereferencing a void pointer, argued by
Robert and accepted with qualifications by Keith as being valid>
Also, what do you think about the following?

int main(void)
{
struct foo;
struct foo *ptr;
*ptr;
struct foo {
int x;
};
return 0;
}

Since struct foo is an incomplete type, I would think that the same
logic would lead us to conclude that *ptr is legal. (gcc 4.0.0 says
"error: dereferencing pointer to incomplete type".)

See Stan Tobias' post in the recent thread gcc: pointer to array:
http://groups-beta.google.com/group/...c8d77b7?hl=en&

In short, *ptr is undefined behaviour by 6.3.2.1#2. Dereferencing a void
pointer does not yield an lvalue so the same paragraph does not apply.

[Robert Gamble]

Keith Thompson wrote:

"Robert Gamble" <rg*******@gmai l.com> writes:

Keith Thompson wrote:
[snip]

That doesn't prove anything. gcc, even in conforming mode, produces
warnings rather than error messages for things that are constraint
violations as far as the standard is concerned.

The standard requires a diagnostic for any syntax error or constraint
violation. Either a warning (which allows the compilation to succeed)
or an error message (which does) qualifies as a diagnostic. And, of
course, it's allowed to produce any additional diagnostics it likes.

We can't tell from the above output whether the warning is a required
diagnostic or not.

The assertion made by Emmanuel was that all compilers that he was aware
of forbade the dereferencing of void pointers. He didn't mention any
of these compilers but gcc was obviously one of them. I produced a
program that was successfully compiled on several versions of gcc inn
strictly-conforming mode, none of why "forbade" my doing so. When
pressed, Emmanuel could not back up his claims (see his response).
Additionally, the other compilers I tried in strictly-conforming mode
produced no messages at all.

Ok, as a refutation of what Emmanuel wrote, it's fine.

[snip]

C99 6.5.3.2p2 says

The operand of the unary * operator shall have pointer type.

6.5.3.2p4 says

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.

It seems ambiguous to me.

Well, lets break it down then:

'The operand of the unary * operator shall have pointer type.'

I think we agree that this is clear.

Sure.

'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.'

This is the part that makes me suspicious. It tells us what the
result is in two out of three cases (points to a function, points to
an object, but not points to an incomplete type). When something in
the standard covers some cases but is silent on others, I tend to
think (correctly or not) that the authors just didn't think about it.

The operand does not point to a function and it does not point to an
object (if you disagree with this, see the discussion on comp.std.c but
bear with me) so this part does not apply to void pointers.

I'll agree that a void* pointer does not point to an object in the
context of this section.

'If the operand has type "pointer to type", the result has type "type"'

For a "pointer to void" the result has type "void". I think this is as
clear as you can expect.

I think I agree -- but on the other hand, one could argue that a
result is a value, and since there are no values of type void, we have
a contradiction.

There is no requirement that a result have a value, it certainly isn't
a value in and of itself.

'If an invalid value has been assigned to the pointer, the behavior of
the unary * operator is undefined.'

Thus, dereferencing an uninitialized void pointer or a void pointer
initialized to NULL would invoke undefined behavior.

The only thing I think is capable of being misunderstood here is
whether a void pointer "points to an object". If you think the
Standard says it does, then the following sentence would be an obvious
contradiction, a void type cannot be an lvalue.

I don't think there is an obviously correct interpretation of this.
I tend to think that allowing dereferencing a void pointer as long as
you don't try to use the value is the least ugly interpretation,
especially given the precedent of calling a void function. On the
other hand, if dereferencing a void pointer were illegal, I don't
think it would break any code that doesn't deserve to be broken.

Upthread, you mentioned that there have been several DRs confirming
that dereferencing a void* is legal. Do you have pointers to these?

http://www.open-std.org/jtc1/sc22/wg...cs/dr_012.html
http://www.open-std.org/jtc1/sc22/wg...cs/dr_106.html
I thought there was another but I may be wrong.
Also, what do you think about the following?

int main(void)
{
struct foo;
struct foo *ptr;
*ptr;
struct foo {
int x;
};
return 0;
}

Since struct foo is an incomplete type, I would think that the same
logic would lead us to conclude that *ptr is legal. (gcc 4.0.0 says
"error: dereferencing pointer to incomplete type".)

First off, *ptr is undefined behavior (even after the type it points to
is completed) because the value of ptr is indeterminate, but let's but
that aside for now.

At the point where ptr is dereferenced, it is a pointer to an
incomplete type. The result is therefore an incomplete type (If the
operand has type "pointer to type", the result has type "type").

The first sentence of 6.3.2.1p1 states:
'An lvalue is an expression with an object type or an incomplete type
other than void; if an lvalue does not designate an object when it is
evaluated, the behavior is undefined.'

The first part of this sentence tells us that the result of *ptr is an
lvalue, the second part tells us that since it does not designate an
object the behavior is undefined allowing gcc to refuse to compile the
program.

Robert Gamble