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.

[Netocrat]

On Thu, 04 Aug 2005 01:14:30 -0700, Tim Rentsch wrote:

"Netocrat" <ne******@dodo.com.au> writes: <snip>

I don't see any reason for void to be/have a value.

.... It's a little nicer, and just as consistent, to think of
void as having a single value that, because it's always the
same, takes zero bits to store, and is completely optimized
in both space and run-time by all C compilers. <snip>

OK void could be defined as a type with a single unique empty value as
you and Chris describe, but it seems contrary to the purpose of void,
which is to represent an expression that does something (has side effects)
but doesn't result in a direct value. To me the value of void as a value
is valueless.
There could be a problem with
void arrays, since the usual calculation for number of
elements ('sizeof x / sizeof *x') doesn't work if 'sizeof x'
is zero, but that minor difficulty can easily be gotten
around.

Somewhat tongue-in-cheek, but only somewhat.

I don't even want to contemplate Chuck's reaction to a discussion of void
arrays. ;)

[S.Tobias]

Tim Rentsch <tx*@alumnus.caltech.edu> wrote:

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:

Tim Rentsch <tx*@alumnus.caltech.edu> wrote:

> For example,
> 'void' functions in C++ are allowed to 'return' void
> expressions, to simplify certains kinds of automatic code
> generation;

[OT] I think you're wrong, both in C and in C++ `return' works the same.
I miss this feature, too.

I double checked via a Google search, and turned up these
pages (among others):

http://www.ittips.com/computersindex_v2-103-1.htm
http://www.edg.com/cpp_ftrs.html

So it seems like the latest version of the C++ standard
does support 'return' with void expressions for 'void'
functions.

Thanks, I wasn't aware of that, you're right. I've looked into
the C++03 Std now, and it agrees with you.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Tim Rentsch]

Netocrat <ne******@dodo.com.au> writes:

On Thu, 04 Aug 2005 01:14:30 -0700, Tim Rentsch wrote:

"Netocrat" <ne******@dodo.com.au> writes:

<snip>

I don't see any reason for void to be/have a value.

...

It's a little nicer, and just as consistent, to think of
void as having a single value that, because it's always the
same, takes zero bits to store, and is completely optimized
in both space and run-time by all C compilers.

<snip>

OK void could be defined as a type with a single unique empty value as
you and Chris describe, but it seems contrary to the purpose of void,
which is to represent an expression that does something (has side effects)
but doesn't result in a direct value. To me the value of void as a value
is valueless.

Rather than thinking of void as a type that means "no value"
you might think of void as a type whose sole value is "empty".
The empty set is still a set, even though it is empty.

The value of a void expression, because it is "worthless", is
discarded.

Again, somewhat tongue in cheek. However, I think this view
is equally consistent, and it could simplify treatment of void
expresssions.

[S.Tobias]

Netocrat <ne******@dodo.com.au> wrote:

On Thu, 04 Aug 2005 08:38:28 +0000, S.Tobias wrote:

Netocrat <ne******@dodo.com.au> wrote:

<snip>

I think that "unknown" is a more appropriate type for
this pointer. Pointing to an object of unknown type makes more sense
than pointing to an object of a type not allowed to be an object.

I think "unknown" is the word for type `void'. If C had an `unknown'
type, would it be in any way different than `void'?

Its definition would limit it solely to use as a pointed-to type for a
generic pointer to any object. Dereferencing such a pointer would not
be possible (the pointed-to type is unknown).

Equivalent solution would be to disallow dereferencing `void*' (while
still allowing void expressions).

Another way to look at `void' is to call it "empty", and apply
it to whatever fits that emptiness (void expressions, which represent
"Nothing", and pointers to "Unknown" which can't point to any concrete
value).

Perhaps the name "void" is is a little bit "overloaded" in that in `void*'
it means a slightly different thing than in plain `void'.
Personally, I'm quite happy with the simple way it is now and I wouldn't
welcome any changes there.

void *obj = malloc(19);
We have obj pointing to an object of void type. We have *obj an
lvalue.
I don't believe it's intended to be specified as an lvalue by the
standard, although as Stan Tobias argues it may unintendedly be.

I don't remember doing that.

Must be a case of identity theft then. Someone recently started an entire
thread devoted to the issue on comp.std.c in your name.

:-)
Oh, you mean that one... But I strongly believe that void expressions
aren't lvalues and should never be, even if the Std says otherwise. ;-)

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Free Bird]

Netocrat wrote:

Chris Dollin wrote:

Netocrat wrote:

Chris Dollin wrote:
> Netocrat wrote:
> > On Tue, 02 Aug 2005 14:39:57 +0100, Chris Dollin wrote:
> >> Netocrat wrote: *snip*> >>> Given that a void type can't
> >>> have a value, the use of the term "expression" seems appropriate.
> >>
> >> `Expression` *cannot* be right; expressions are things that the
> >> grammar describes and the compiler handles, but they don't have to
> >> exist at run-time, when evaluation takes place.
> >
> > Is it evaluated?
>
> Is there something in the Standard that prevents it?

6.3.2.2#1: "The (nonexistent) value of a void expression (an expression that has type void) shall not be used in any way [...] (A void
expression is evaluated for its side effects.)"

So it is evaluated,

There are no side effects to dereferencing a void pointer.

What if it is volatile?

[Netocrat]

On Sat, 06 Aug 2005 20:41:44 +0000, wrote:

Netocrat wrote:

Chris Dollin wrote:

> Netocrat wrote:
>
> > Chris Dollin wrote:
> >> Netocrat wrote:
> >> > On Tue, 02 Aug 2005 14:39:57 +0100, Chris Dollin wrote:
> >> >> Netocrat wrote: *snip* > >> >>> Given that a void type can't
> >> >>> have a value, the use of the term "expression" seems appropriate.
> >> >>
> >> >> `Expression` *cannot* be right; expressions are things that the
> >> >> grammar describes and the compiler handles, but they don't have to
> >> >> exist at run-time, when evaluation takes place.
> >> >
> >> > Is it evaluated?
> >>
> >> Is there something in the Standard that prevents it?
> >
> > 6.3.2.2#1: "The (nonexistent) value of a void expression (an expression > > that has type void) shall not be used in any way [...] (A void
> > expression is evaluated for its side effects.)"
>
> So it is evaluated,

There are no side effects to dereferencing a void pointer.

What if it is volatile?

Still not a side effect. The pointer does not reference an object with a
value, so there is nothing that may have changed.

[Netocrat]

On Sat, 06 Aug 2005 17:32:37 +0000, S.Tobias wrote:

Perhaps the name "void" is is a little bit "overloaded" in that in
`void*' it means a slightly different thing than in plain `void'.
That's the issue exactly.
Personally, I'm quite happy with the simple way it is now and I wouldn't
welcome any changes there.

Oh I'm not seriously advocating a new type - it all works fine in
practice. I'm just pointing out that as you seem to agree there's a
little conceptual inconsistency in the model. It would be cleared up
by not using void* for an unknown pointer.