CAN WE TYPE CAST AN INTEGER AS (VOID *)X..(Like can I return a value (void *)x)

now suppose  I have declared an integer value inside a function as
int x;
now if the return type of the function is of type (void *) then can I
write
return((void *)x)  in side the function?
I came across this in a document on multithreading in C..I can post the
exact portion of code which works correctly with such an assignment if
you people want.
Please clarify my doubt.I hope I have conveyed it properly.

Hello Abhishek,

Please do not write sentences in ALL UPPERCASE. This will only cause
people to ignore your posts, since this is a style which is often used
by spammers. Also, try to keep your subject short, since some people
might be using newsreaders which are not able to display too long
subject lines. A good subject for your post might have been something
like "Casting int to void *"

Abhishek <abhisheksgumadi@gmail.com> wrote:

> now suppose I have declared an integer value inside a function as int
> x; now if the return type of the function is of type (void *) then can
> I write return((void *)x)  in side the function?

Yes, this is possible, but I suspect this might result in undefined
behaviour. By casting an int to a void pointer, you take the number in
x, and convert it to an address. You are telling your compiler `trust
me, I know what I am doing. Although this is just a regular number, I am
sure this number is a valid address of something which doesn't have a
specific type'. This might or might not work on your platform, since
there is no guarantee that an int might fit into a pointer. I am not
aware of any good reasons for using an integer type to store a pointer,
although I am aware of other code where this is common practice (the
Linux kernel). Maybe somebody else can explain why this is done.

Ico

--
:wq
^X^Cy^K^X^C^C^C^C

Ico wrote:

> Hello Abhishek,
>
> Please do not write sentences in ALL UPPERCASE. This will only cause
> people to ignore your posts, since this is a style which is often used
> by spammers.

I must say, my immediate reaction to ALL CAPS tends to be STOP
SHOUTING! ;-)

<snipped more good advice>

> Abhishek <abhisheksgumadi@gmail.com> wrote:
> 
>
> Yes, this is possible, but I suspect this might result in undefined
> behaviour. By casting an int to a void pointer, you take the number in
> x, and convert it to an address. You are telling your compiler `trust
> me, I know what I am doing. Although this is just a regular number, I
> am sure this number is a valid address of something which doesn't have
> a specific type'. This might or might not work on your platform, since
> there is no guarantee that an int might fit into a pointer. I am not
> aware of any good reasons for using an integer type to store a
> pointer, although I am aware of other code where this is common
> practice (the Linux kernel). Maybe somebody else can explain why this
> is done.

This is certainly undefined behaviour, if not worse. Once you return
from the function, as far a C Standard is concerned, all objects local
to that function _cease_to_exist_ (as was mentioned elsewhere in c.l.c,
Standard knows nothing about stacks and similar real world concepts).
Referring to them outside the function should really make your head
spin. ;-)

Of course, an implementation is allowed to take shortcuts by not
bothering to physically destroy such objects, and so you may not get
illegal access or whatever error is appropriate. However, even changing
optimisation level, let alone the whole compiler may make your (OP's)
code behave in a totally different way.

Cheers

Vladimir

Cheers

Vladimir

--
"We are upping our standards ... so up yours."
-- Pat Paulsen for President, 1988.

Vladimir S. Oka <novine@btopenworld.com> wrote:
> Ico wrote:
> 
>
> This is certainly undefined behaviour, if not worse. Once you return
> from the function, as far a C Standard is concerned, all objects local
> to that function _cease_to_exist_ (as was mentioned elsewhere in c.l.c,
> Standard knows nothing about stacks and similar real world concepts).
> Referring to them outside the function should really make your head
> spin. ;-)
>
> Of course, an implementation is allowed to take shortcuts by not
> bothering to physically destroy such objects, and so you may not get
> illegal access or whatever error is appropriate. However, even changing
> optimisation level, let alone the whole compiler may make your (OP's)
> code behave in a totally different way.

Vladimir, I think you misread the details in the OP's question: as far
as I onderstood, he is not returning the address of x, but the *value*
of x, casted to void * :
 

Apart from the cast, this is just as valid as returning x intself.

Ico

--
:wq
^X^Cy^K^X^C^C^C^C

Ico wrote:

> Vladimir S. Oka <novine@btopenworld.com> wrote: 

< snipped getting ahead of myself >

> Vladimir, I think you misread the details in the OP's question: as far
> as I onderstood, he is not returning the address of x, but the *value*
> of x, casted to void * :
> 
>
> Apart from the cast, this is just as valid as returning x intself.

Ah, you're absolutely right (and so is Eric). I stand corrected.

I think I jumped ahead of myself (and OP), thinking of what one would
_do_ with such a value returned from the function. Trying to
dereference it would most likely be a bad idea (unless maybe one is
implementing a *alloc() replacement).

Cheers

Vladimir


--
Democracy is a device that insures we shall be governed no better than
we deserve.
-- George Bernard Shaw

Ico wrote:

> Vladimir S. Oka <novine@btopenworld.com> wrote: 
>
> Vladimir, I think you misread the details in the OP's question: as far
> as I onderstood, he is not returning the address of x, but the *value*
> of x, casted to void * :
> 
>
> Apart from the cast, this is just as valid as returning x intself.
>
> Ico
>

Vladimir, you muppet! You are henceforth barred from posting before 9 AM
and/or before having at least three (3) mugs of strong coffee!

The above applies to my previous reply, especially (which I still can't
see, and think will have to do un/re-subscribe to c.l.c dance again)!

Clerk, please strike Vladimir's statements in this case.

I'm kneeling on some corns for a while... :-(

Cheers

Vladimir

--
Hark ye, Clinker, you are a most notorious offender.  You stand
convicted of sickness, hunger, wretchedness, and want.
-- Tobias Smollet

Eric Sosman wrote:
>      The O.P. has run across a function whose return type is
> `void*' <ot> because of the requirements of a framework that
> is not topical here </ot>.  However, in the context of the
> actual function it makes more sense to return an `int'.  The
> code tries to do so by converting the `int' to a `void*';
> presumably, the caller retrieves the `void*' and converts it
> back to an `int' again.  The O.P. asks whether C guarantees
> that this will work as desired.
>
>      The answer (may I have the envelope, please?) is "No."
>
>      That said, the dubious practice will in fact work as desired
> on many implementations (I suspect it might fail on AS/400, but
> I'm not sure of that).  Completely portable approaches exist,
> but some programmers are too lazy or too unimaginative to use
> them.  The O.P. is looking at such a programmer's product.

A portable solution within this framework is to make x static
and return its address. Then convert back to (int *) in the
calling function.