type casting integer to void*

Question

#include <stdio.h>
void pass(void* );
int main()
{
    int x;
    x = 10;
    pass((void*)x);
    return 0;
}
void pass(void* x)
{
   int y = (int)x;
   printf("%d\n", y);
}


output: 10

my questions from the above code..

1. what happens when we typecast normal variable to void* or any pointer variable?

2. We have to pass address of the variable to the function because in function definition argument is pointer variable. But this code pass the normal variable ..

This format is followed in linux pthread programming... I am an entry level C programmer. I am compiling this program in linux gcc compiler..

Solution

I'm only guessing here, but I think what you are supposed to do is actually pass the address of the variable to the function. You use the address-of operator & to do that

int x = 10;
void *pointer = &x;

And in the function you get the value of the pointer by using the dereference operator *:

int y = *((int *) pointer);

Comments

[Daniel Fischer]

"what happen when typcating normal variable to void* or any pointer variable?" Implementation-dependent. Note that it's not guaranteed that casting an int to void* and back yields the original value (though usually, it does).

[David Heffernan]

What are you actually trying to achieve?

[Rerito]

Generally this kind of type casting does not lead to any concern as long as the addresses are encoded using the same length as the "variable type" (int in your case). But @DanielFischer is right the risk is that you would lose some information if the storage capacity of your variable is less than the address length. Thus, something like void *ptr1 = a_pointer(); char ptr_c = (char)ptr1; void *ptr2 = (void*)ptr_c; would lead to the assertion ptr1 != ptr2

[David Heffernan]

"I think what you should do is actually pass the address of the variable to the function" Not necessarily. If this is the data to a thread procedure, then you quite commonly want to pass by value.

[Some programmer dude]

@DavidHeffernan I rephrased that sentence a little.

[David Heffernan]

If you are going to pass the address you typically need to exert some more control over the lifetime of the object. Usually that means the pointer is allocated with malloc and then destroyed by calling free in the thread proc. Automatic storage isn't what you need for thread proc. I know the code in Q is not for thread proc, but it's clearly mentioned as the motivation.

[Shahbaz]

@DavidHeffernan, sane thread APIs wouldn't send integral data to the thread procedures, they would send pointers. Even though what you say regarding the lifetime of the object is true, integral types are too limited for a generic API.

[Rerito]

And in this context, it is very very very common to see programmers lazily type cast the void * to something like int. Anyway, if the OP wants a paranoid scheme, he can still malloc the appropriate amount of data to pass its value using a pointer !

[Shahbaz]

On the contrary, there is a need to repeat the text here. That link will sooner or later rot, turning your answer to a completely useless one. See here for more information.

[Shahbaz]

You don't necessarily have to. You could also keep the parameters global, or even on the stack, if it's the same function who calls pthread_create and pthread_join which is quite often the case (main creates threads and then joins them before exit).

[Giacomo Tesio]

@Shahbaz you could... but I will not suggest to a C newbie to use globals. As for the stack, I've written a few libraries using pthreds, thus I don't agree that what you describe "is quite often the case". But, sure, in that specific case you can pass a local variable address, if you know what you are doing.

[Kaiepi]

This also works: int x = 10; void *pointer = &(int){ x };