void *

[Roman Mashak]

Your understanding is going nowhere, I'm afraid - but that can be fixed,
if only you can put down your void * and your cast and your &, and
instead tell us what you're trying to do.

I want to hold pointers on to objects of various types in the structurre
member, named 'data'. I declared it as 'void *' and faced various problems

 

[Roman Mashak]

That still isn't very clear. What real world problem are you trying to
solve? Here's my guess at what you want:

A container that can store any kind of object, such that you can process
the object (create it, initialise it, copy it, compare it, change it,
print it, etc) without the container knowing anything about its type.

Is that right?

I'm implementing single linked list, with such traditional node's structure:

struct list_node
{
void *data;
struct list_node *next;
};

I want to store in my LL objects of different types: ints, longs, chars etc.
My assumption was that declaring a structure member as 'void *' may help me
(please also check my reply to Flash Gordon).

 

[Richard Heathfield]

Roman Mashak said:

I apologize, gentlemen, but I misled you. I expressed myself with
ambiguity and need to correct now. What I really want is 'void *data'
member to store
_pointers_ to objects of various types (say, 'int', 'long', 'char' in
the first place), I confused two terms 'object' and 'pointer to
object'.

In which case this is (a) easy and (b) probably pointless. void * can
point to any object type without any problem:

#include <stdlib.h>

struct llnode
{
void *data;
struct llnode *next;
};

/* llnode_add - adds a new node to a linked list. A pointer to the
existing head of the list is passed in (or NULL if the list is
currently empty). The new node becomes the new head of the list,
and a pointer to it is returned. (If the storage can't be
allocated, NULL is returned.)
*/
struct llnode *llnode_add(struct llnode *head, void *data)
{
struct llnode *new = malloc(sizeof *new);
if(new != NULL)
{
new->data = data;
new->next = head;
}
return new;
}

But this will only point to data. It won't know what kind of data it
points to, how big it is, how to process it, or anything like that. And
it won't "own" the data, so you have to do that, and you have to know
when to remove items from the list as and when they go out of scope
(and which items they are). This is a recipe for a million headaches.

 

[Army1987]

This is *not* getting a pointer to an int, it is coercing an int in to
an int pointer. There is no guarantee that all int values can be
converted to pointers.

[...]

Quibble: Well, yes, it is guaranteed. The result is
implementation-defined, and can even be a trap representation.
In particular, different integer values may convert to the same
pointer value (and almost certainly will if the integer type is
bigger than the pointer type).

"Almost"? Ever heard of the pidgeonhole principle?

 

[Chris Dollin]

This is *not* getting a pointer to an int, it is coercing an int in to
an int pointer. There is no guarantee that all int values can be
converted to pointers.

[...]

Quibble: Well, yes, it is guaranteed. The result is
implementation-defined, and can even be a trap representation.
In particular, different integer values may convert to the same
pointer value (and almost certainly will if the integer type is
bigger than the pointer type).

"Almost"? Ever heard of the pidgeonhole principle?

Isn't the implementation allowed to raise a signal on the conversion? In
which case, it could be that /some/ integers won't convert at all, and hence
don't convert to values equal to those from some other integer which
does convert.

 

[Dave Vandervies]

Isn't the implementation allowed to raise a signal on the conversion? In
which case, it could be that /some/ integers won't convert at all, and hence
don't convert to values equal to those from some other integer which
does convert.

A sufficiently perverse implementation could even generate a *different*
signal for every non-convertable pointer, so that not even the best
nitpicker could claim that it's producing the same result for two
different pointers.


dave

 

[Walter Roberson]

A sufficiently perverse implementation could even generate a *different*
signal for every non-convertable pointer, so that not even the best
nitpicker could claim that it's producing the same result for two
different pointers.

signal takes an int as its signal number, so if the integer type
is wider than sizeof(int) + sizeof(void*) you wouldn't be
able to generate different signal for each one.

 

[Roman Mashak]

I apologize, gentlemen, but I misled you. I expressed myself with ambiguity
and need to correct now. What I really want is 'void *data' member to store
_pointers_ to objects of various types (say, 'int', 'long', 'char' in the
first place), I confused two terms 'object' and 'pointer to object'.

Now I realized that casting is a wrong way and better solution would be to
have a callback function with a parameter indicating the real type,
somewehat like this:

enum e_types {
e_int,
e_long,
e_char
};
typedef e_types e_types;

node* list_add_head(node **head, int(func *)(void *data, e_types t))
{
....
}

Where (func *) is to handle the types properly. Am I on right path?

 

[Keith Thompson]

This is *not* getting a pointer to an int, it is coercing an int in to
an int pointer. There is no guarantee that all int values can be
converted to pointers.

[...]

Quibble: Well, yes, it is guaranteed. The result is
implementation-defined, and can even be a trap representation.
In particular, different integer values may convert to the same
pointer value (and almost certainly will if the integer type is
bigger than the pointer type).

"Almost"? Ever heard of the pidgeonhole principle?

Yes, "almost". Think about padding bits. I carefully said "integer
values", not "integer representations".

 

[Keith Thompson]

[...]
This is *not* getting a pointer to an int, it is coercing an int in to
an int pointer. There is no guarantee that all int values can be
converted to pointers.
[...]

Quibble: Well, yes, it is guaranteed. The result is
implementation-defined, and can even be a trap representation.
In particular, different integer values may convert to the same
pointer value (and almost certainly will if the integer type is
bigger than the pointer type).

"Almost"? Ever heard of the pidgeonhole principle?

Isn't the implementation allowed to raise a signal on the
conversion? In which case, it could be that /some/ integers won't
convert at all, and hence don't convert to values equal to those
from some other integer which does convert.

Surprisingly, no, an integer-to-pointer conversion cannot raise a
signal. An integer-to-integer-conversion either yields an
implementation-defined result or raises an implementation-defined
signal if the target type is signed and the result can't be
represented; the permission to raise a signal is new in C99. There is
no such permission for integer-to-pointer conversions; they merely
yield an implementation-defined result (except in the special case of
null pointer constants). Attempting to *use* that result can invoke
undefined behavior, though, which of course can include raising a
signal.

 

[Manish Tomar]

No, but it could have an enum member which had values defined for

e_char, e_short, e_int, e_long, e_float, e_double, e_struct_1, etc so
that any code that needed to manipulate whatever data pointed to could
determine the real type.

I personally don't think using an enum to stores types is a good idea
mainly because, the implementation is doing more than it should. It
should not involve in knowing the type of data and deciding how to
handle it. Also, it would become difficult to extend this modal for
user specific data using structures. Taking standard lib qsort as
example, I would recommend callback without type as possible solution.

Regards,
Manish
(http://manishtomar.blogspot.com)

 

[pete]

printf("data %p\n", head->data);

My preferred way of writing that, is:

puts(head -> data);

 

[Keith Thompson]

My preferred way of writing that, is:

puts(head -> data);

Your statement does something completely different from the printf.

 

[Barry Schwarz]

My preferred way of writing that, is:

puts(head -> data);

But they don't do the same thing.

The printf version writes the address contained in the
pointer.

The puts version writes the string the pointer points to.


Remove del for email

 

[pete]

Your statement does something completely different from the printf.

I take it all back.

 

[Richard]

Richard said:



I'm just trying to find out what he actually wants to do, which is still
far from clear (although clearer than it was).

If you really want to help him, why not answer his question yourself?


If you think it's clear, answer it yourself.

It is incredibly clear to anyone who allowed themselves to think like a
human.

What else could

"I want to hold pointers on to objects of various types"

compile too in your thinking? It is clear as day, especially in the
light of the demo code he posted.

I hope to hell you are not a teacher of any kind.

 

[Richard Heathfield]

[Much context snippage. What I've left is my actual question ("why not
answer his question yourself?") and the fresh text "Richard" added in
his so-called reply.]

Richard said:

Richard Heathfield <[email protected]> writes:

It is incredibly clear to anyone who allowed themselves to think like
a human.

What else could

"I want to hold pointers on to objects of various types"

compile too in your thinking? It is clear as day, especially in the
light of the demo code he posted.

I hope to hell you are not a teacher of any kind.

So there we have it. "Richard" is not interested in answering the
original question and helping the original questioner. If he were, he
would have provided an answer. Instead, he continues to carp. Well,
that's up to him, but he has damaged his credibility by claiming to be
interested in helping the OP and yet passing up this golden opportunity
to demonstrate the fact by actually doing so.