(void**)&ppval

[Oliver Block]

Hello,

sometimes you can read that a function requiring an argument of tpye
void ** is submitted something like the following:

mystruct **ppval;

myfunc((void **)&ppval, ...);

I would expect that one would instead use

myfunc((void **)ppval, ...);

Why would one use the first and what is the difference to using the
second call?

Regards,

Oliver Block

[Keith Thompson]

Eric Sosman <Er*********@su n.comwrites:

Oliver Block wrote On 09/04/07 11:01,:

>Hello,

sometimes you can read that a function requiring an argument of tpye
void ** is submitted something like the following:

mystruct **ppval;

myfunc((void **)&ppval, ...);

I would expect that one would instead use

myfunc((void **)ppval, ...);

Why would one use the first and what is the difference to using the
second call?

Both are probably wrong.

One possibility is that the author of myfunc() assumed
that all data pointers have the same representation. He's
trying to use the void** argument to find his way to some
other pointer in memory, and then trying to manipulate that
other pointer as if it were a void*, regardless of what it
actually is. If this is the case, myfunc() is a bug looking
for a place to sting. It will find one as soon as it's run
on a machine where different "flavors" of pointers exist.

[...]

Right. 'void*' can be used as a generic pointer type. Any pointer
value (well, any pointer-to-object value, not a function pointer) can
be converted to void* and back again with no loss of information,
and the conversion can be done implicitly.

It's tempting to use 'void**' as a generic pointer-to-pointer type,
but there is no generic pointer-to-pointer type.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ark Khasin]

Chris Torek wrote:
<snip>

The way this works, in theory if not always in practice, is by
making "void *" be a super-cali-fragialistic-expialidocious, huge
fat MEGA-pointer, capable of holding every other kind of data
pointer, almost as if it were a C "union" of all the various
data-pointer types (but slightly different, in that some sort of
conversion is involved). In practice, what it really means is that
"void *" can point to *any* byte[%] of data within the C run-time
system's address space.

<snip>

On some machines -- rare today -- the machine's "native" pointer
type points to "machine words" that are bigger than a single C
byte. For instance, a machine might have four billion "words" of
RAM (4 giga-"words", rather than 4 giga-"bytes") where each "word"
is 32 bits wide. (This machine thus has 16 gigabytes of RAM,
addressable using only a 32-bit address bus. Addresses go from 0
to 4294967295 as usual, but each address gives you a full 32-bit
"machine word", hence the 16 gigabytes of RAM with only 4 gigabytes
of machine-word-addresses.)

<snip>

In the past, this "use some extra bits to tell which `C byte' to
manipulate within the machine word" method was more common. Some
pointers (like "int *") were ordinary, "skinny", machine pointers;
others ("char *" and a few more) were "fat" pointers containing
both a machine-level "skinny" pointer, and some more information.

Since "void *" also must point to any "C byte", "void *" is also
"fat" on this kind of system.

<snip>
Just wondering:
Is void * pointer the fattest there is or can const void * be even
fatter? (Thinking of a machine with 2K of RAM and 1023.5G of ROM :-)
Thanks,
-- Ark

[Justin Spahr-Summers]

On Sep 4, 11:49 pm, Ark Khasin <akha...@macroe xpressions.comw rote:

Just wondering:
Is void * pointer the fattest there is or can const void * be even
fatter? (Thinking of a machine with 2K of RAM and 1023.5G of ROM :-)

"A pointer to void shall have the same representation and alignment
requirements as a
pointer to a character type. Similarly, pointers to qualified or
unqualified versions of
compatible types shall have the same representation and alignment
requirements." (C99)

So, no, const void * cannot be fatter.

[Barry Schwarz]

On Wed, 05 Sep 2007 04:49:38 GMT, Ark Khasin
<ak*****@macroe xpressions.comw rote:

>Just wondering:
Is void * pointer the fattest there is or can const void * be even

The standard only guarantees that an object pointer converted to a
void* and back comes back equal. It says nothing about relative
sizes.

>fatter? (Thinking of a machine with 2K of RAM and 1023.5G of ROM :-)

The standard does guarantee that qualified types have the same size
and representation as unqualified types.

Using your example, if there were a string literal in ROM, its address
(which perhaps should be const char*) could be assigned to a char* so
that would have to be fat enough. Since char* and void* have the same
size and representation, void* must be fat enough also.
Remove del for email