Casting a pointer to an int and back
pinkflo...@gmail.com
Like:
typedef struct
{
int whatever;
} S;
int main(void)
{
S* s = malloc(sizeof(S));
int i = (int) s;
S* t = (S*) i;
t.whatever = 42;
etc.
}
/David
Vladimir S. Oka
No, it is not.
You may be lucky that it works on your implementation, but don't count
on it (i.e. it's not portable).
Some concerns:
- how do pointers map to integers?
- how do integers map to pointers (not necessarily same as above)?
- is an integer wide enough to hold an address value (even if above is
fine)?
Even if all of the above are fine for one implementation/architecture,
the may not be on others.
Just don't do it. Also, have a look at other things you got wrong,
below:
> Like:
#include <stdlib.h>
Otherwise `malloc` is unknown.
> typedef struct
> {
> int whatever;
> } S;
>
> int main(void)
> {
> S* s = malloc(sizeof(S));
> int i = (int) s;
> S* t = (S*) i;
> t.whatever = 42;
You certainly mean:
t->whatever = 42;
or
(*t).whatever = 42;
> etc.
This is a syntax error.
Please post full, compileable, minimal examples.
> }
--
BR, Vladimir
Richard G. Riley
Well spotted. Go to top of the pedants class.
Grumble
I don't think so.
For example, on some platforms,
sizeof(int) = 4 and sizeof(void *) = 8
Vladimir S. Oka
Yes! I finally made it!
Snipping relevant parts of the post is bad etiquette. I also said:
> > Please post full, compileable, minimal examples.
Which was the whole point. It's in the OP's interest, really.
--
BR, Vladimir
SM Ryan
# Is it well-defined to make a cast from a pointer to an int and back?
# Like:
You can cast to some integer, but not necessarily an int. However
because so much legacy code depends on this working, compilers
will generaly do whatever is necessary to make it work.
You shouldn't need to cast ints to/from pointers anymore unless
you need to enter absolute address or similar issues. (void*)
can be assigned any data pointer the same way int used to be
a universal pointer type.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
Mention something out of a Charleton Heston movie, and suddenly
everybody's a theology scholar.
Richard Bos
On two conditions:
- that the cast from pointer to int doesn't lose any information, i.e.,
that an int is wide enough to hold all pointer values;
- that the pointer is cast to int and then back to the _same_ pointer
type;
AFAICT this is well-defined.
The second condition, only you yourself have any influence over. Just
don't convert a pointer to an integer and then to a different pointer
type. In this case, you're OK.
The first depends on the platform. If you have C99, you may be able to
use (u)intptr_t, which are integer types (not necessarily ints) capable
of holding any void * value safely. Declare i as intptr_t, and cast s to
void * before assigning it to i, and back the other way 'round, too:
intptr i = (int)(void *)s;.
S *t = (void *)i;
You don't need a cast to (S *) in the second line, since a void * will
be automatically and correctly converted to any object pointer type.
Unfortunately, these types are optional, and they don't exist in C89 at
all. If it's unavailable to you, you may just have to resort to using
unsigned long (or unsigned long long) and hoping that that's large and
well-aligned enough. It probably is, but it's not guaranteed. If you
have intptr_t, use it.
Richard
ais523
> "pinkflo...@gmail.com" <pinkflo...@gmail.com> wrote:
> # Is it well-defined to make a cast from a pointer to an int and back?
> # Like:
>
> You can cast to some integer, but not necessarily an int. However
> because so much legacy code depends on this working, compilers
> will generaly do whatever is necessary to make it work.
int large enough to hold any sort of pointer.
Richard G. Riley
The snipped part had no relevance on my pithy reply to your pedant
prize winning reply. The guy was asking a question about casting : not for a
code review or smart assed comments on "etc." being a syntx error.
The fact that he didnt put in the includes and did include the ".etc"
would, to me, indicate that he was pseudo coding a bit to get an
answer to the pertient question which was "can one cast between
pointers and ints". I'm sure many others would have made this leap in
logic too : it is, after all, a programming language group :)
Or do you insist on working, compilable code for all questions on
casts?
Come on. Admit it. You were over the top
Vladimir S. Oka
Richard G. Riley wrote:
> On 2006-02-22, Vladimir S. Oka <nov...@btopenworld.com> wrote:
> > Richard G. Riley wrote:
> >> On 2006-02-22, Vladimir S. Oka <nov...@btopenworld.com> wrote:
> >> >> etc.
> >> >
> >> > This is a syntax error.
> >>
> >> Well spotted. Go to top of the pedants class.
> >
> > Yes! I finally made it!
> >
> > Snipping relevant parts of the post is bad etiquette. I also said:
> >
> >> > Please post full, compileable, minimal examples.
> >
> > Which was the whole point. It's in the OP's interest, really.
> >
>
> The snipped part had no relevance on my pithy reply to your pedant
> prize winning reply. The guy was asking a question about casting : not for a
> code review or smart assed comments on "etc." being a syntx error.
Which question I answered /first/, and than added a few comments as
well. What is your problem with this?
> The fact that he didnt put in the includes and did include the ".etc"
> would, to me, indicate that he was pseudo coding a bit to get an
> answer to the pertient question which was "can one cast between
> pointers and ints". I'm sure many others would have made this leap in
> logic too : it is, after all, a programming language group :)
He obviously wasn't "pseudocoding". His "pseudocode" looked very much
like an attempt at a C program. It actually wasn't even required to
support his question, especially not with the struct.
> Or do you insist on working, compilable code for all questions on
> casts?
Not necessarily working (otherwise there'll be no question, right? ;-)
), but certainly compilable (and not just for the cast questions). Or,
do you always re-type the posted code to try it out?
> Come on. Admit it. You were over the top
Continuing to indulge you? I admit to that.
--
BR, Vladimir
Richard G. Riley
>
> Richard G. Riley wrote:
>> On 2006-02-22, Vladimir S. Oka <nov...@btopenworld.com> wrote:
>> > Richard G. Riley wrote:
>> >> On 2006-02-22, Vladimir S. Oka <nov...@btopenworld.com> wrote:
>> >> >> etc.
>> >> >
>> >> > This is a syntax error.
>> >>
>> >> Well spotted. Go to top of the pedants class.
>> >
>> > Yes! I finally made it!
>> >
>> > Snipping relevant parts of the post is bad etiquette. I also said:
>> >
>> >> > Please post full, compileable, minimal examples.
>> >
>> > Which was the whole point. It's in the OP's interest, really.
>> >
>>
>> The snipped part had no relevance on my pithy reply to your pedant
>> prize winning reply. The guy was asking a question about casting : not for a
>> code review or smart assed comments on "etc." being a syntx error.
>
> Which question I answered /first/, and than added a few comments as
> well. What is your problem with this?
>
You dont see how hiliting that "etc." was a syntax error is extreme to
say the least?
>
> Continuing to indulge you? I admit to that.
>
I shall absolve you from doing so then. You may depart.
"etc. is a syntax error".LOL. It'll make a nice .sig I think.
--
Remove evomer to reply
pete
>
> "pinkflo...@gmail.com" <pinkflo...@gmail.com> wrote:
>
> > Is it well-defined to make a cast from a pointer to an int and back?
> > Like:
> >
> > typedef struct
> > {
> > int whatever;
> > } S;
> >
> > int main(void)
> > {
> > S* s = malloc(sizeof(S));
> > int i = (int) s;
> > S* t = (S*) i;
> > t.whatever = 42;
> > etc.
> > }
>
> On two conditions:
> - that the cast from pointer to int doesn't lose any information,
> i.e.,
> that an int is wide enough to hold all pointer values;
> - that the pointer is cast to int and then back to the _same_ pointer
> type;
> AFAICT this is well-defined.
AFAICT it's implementation defined.
N869
6.3.2.3 Pointers
[#5] An integer may be converted to any pointer type.
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type.49)
[#6] Any pointer type may be converted to an integer type.
Except as previously specified, the result is
implementation-defined. If the result cannot be represented
in the integer type, the behavior is undefined. The result
need not be in the range of values of any integer type.
--
pete
ais523
pete wrote:
OK, it's implementation-defined. But from my reading of C99, it is
still possible either to do it portably or to discover that it can't be
done.
>From WG14/N843 (C99 draft):
# 7.18.1.4 Integer types capable of holding object pointers
# 1 The following type designates a signed integer type with the
property that any valid
# pointer to void can be converted to this type, then converted back to
pointer to void,
# and the result will compare equal to the original pointer:
# intptr_t
# The following type designates an unsigned integer type with the
property that any valid
# pointer to void can be converted to this type, then converted back to
pointer to void,
# and the result will compare equal to the original pointer:
# uintptr_t
# (These types need not exist in an implementation.)
(I don't have the final copy of C99 to check against.)
As INTPTR_MAX is defined in <stdin.h> if and only if intptr_t exists,
it is possible for the preprocessor to determine whether this is
possible or not. Here is some sample code (untested, because I don't
have a C99 compiler):
#include <stdio.h>
#include <stdint.h>
int main(void)
{
int a=6;
int* pa=&a;
#ifdef INTPTR_MAX
{
intptr_t ipt;
ipt=(intptr_t)pa;
*(int*)ipt=8;
printf("%d\n",a);
}
#else
puts("intptr_t doesn't exist.");
#endif
return 0;
}
AFAICT, this will be defined and produce the expected result (printing
8\n) on any implementation where intptr_t exists. If it doesn't, the
program can at least tell it's impossible and print an error message.
Of course, this won't work under C89.
Mark McIntyre
<rgrile...@gmail.com> wrote:
>The snipped part had no relevance on my pithy reply to your pedant
>prize winning reply. The guy was asking a question about casting : not for a
>code review or smart assed comments on "etc." being a syntx error.
You've not been here long have you? If you had, you would be aware
that most regulars will review code *in its entirety*, partly on the
(often correct) assumption that the OP may be completely mistaken
about the cause of their bug, partly out of kindness.
>The fact that he didnt put in the includes and did include the ".etc"
>would, to me, indicate that he was pseudo coding
If you don't post the code that went wrong, how can someone diagnose
it? And if you want to post pseudocode, then say so.
>Or do you insist on working, compilable code for all questions on
>casts?
Yes.
>Come on. Admit it. You were over the top
No, he wasn'.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Richard G. Riley
> On 22 Feb 2006 12:10:39 GMT, in comp.lang.c , "Richard G. Riley"
><rgrile...@gmail.com> wrote:
>
>>The snipped part had no relevance on my pithy reply to your pedant
>>prize winning reply. The guy was asking a question about casting : not for a
>>code review or smart assed comments on "etc." being a syntx error.
>
> You've not been here long have you? If you had, you would be aware
Did you read the OP?
> that most regulars will review code *in its entirety*, partly on the
> (often correct) assumption that the OP may be completely mistaken
> about the cause of their bug, partly out of kindness.
The review of the code wasnt the issue. The question about casting was.
>
>>The fact that he didnt put in the includes and did include the ".etc"
>>would, to me, indicate that he was pseudo coding
>
> If you don't post the code that went wrong, how can someone diagnose
> it? And if you want to post pseudocode, then say so.
So you would have thought that "etc." was his code would you?
This discussion is nothing to do with whether real code should be
posted : of course it should when there is an issue with a bug.
My point of contention is that it doesnt take a genius to realise
that "etc." was not part of any code and the OP was simply asking a
question about casts.
I understood it (the OP) and, as you point out, I havent been "here" long.
Why it takes so many people to police posters looking for help is
foreign to me.
>
>>Or do you insist on working, compilable code for all questions on
>>casts?
>
> Yes.
>
>>Come on. Admit it. You were over the top
>
> No, he wasn'.
> Mark McIntyre
--
Remove evomer to reply
CBFalconer
> Richard G. Riley wrote:
>
>
>> Or do you insist on working, compilable code for all questions on
>> casts?
>
> Not necessarily working (otherwise there'll be no question, right? ;-)
> ), but certainly compilable (and not just for the cast questions). Or,
> do you always re-type the posted code to try it out?
>
>> Come on. Admit it. You were over the top
>
> Continuing to indulge you? I admit to that.
I think the time has come for the following sig.
--
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
Vladimir S. Oka
CBFalconer wrote:
> I think the time has come for the following sig.
Thank you!
I'm posting from the office today, and have to use Google, so I
couldn't easily find it.
--
BR, Vladimir
Richard G. Riley
> "Vladimir S. Oka" wrote:
>> Richard G. Riley wrote:
>>
> ... snip ...
>>
>>> Or do you insist on working, compilable code for all questions on
>>> casts?
>>
>> Not necessarily working (otherwise there'll be no question, right? ;-)
>> ), but certainly compilable (and not just for the cast questions). Or,
>> do you always re-type the posted code to try it out?
>>
>>> Come on. Admit it. You were over the top
>>
>> Continuing to indulge you? I admit to that.
>
> I think the time has come for the following sig.
>
LOL. Ridiculous. How can I be trolling when I am trying to argue
reasonably about *helping* a perfectly clear question? I'm sorry if my
standards of "input" are less exacting than your own. Sometimes
reading betweent the lines can be very rewarding
Jordan Abel
>> Is it well-defined to make a cast from a pointer to an int and back?
>
> No, it is not.
>
> You may be lucky that it works on your implementation, but don't count
> on it (i.e. it's not portable).
It's not a matter of luck; the existence and identity of the integral
type that a pointer may be converted to and back is
implementation-defined [saying "lucky" implies that it is undefined]
> Some concerns:
>
> - how do pointers map to integers?
> - how do integers map to pointers (not necessarily same as above)?
> - is an integer wide enough to hold an address value (even if above is
> fine)?
>
> Even if all of the above are fine for one implementation/architecture,
> the may not be on others.
and since it's implementation-defined, you can look it up in your
platform documentation. (OT: on many platforms, you probably want to use
a long instead of an int.)
Jordan Abel
> "pinkflo...@gmail.com" <pinkflo...@gmail.com> wrote:
> # Is it well-defined to make a cast from a pointer to an int and back?
> # Like:
>
> You can cast to some integer, but not necessarily an int.
And not necessarily any at all. intptr_t is not required to exist, and
there is not required to be such a type. (OT: long is often more likely
to work than int - on linux, for example, the kernel only compiles on
systems where a pointer fits in a long)
> However because so much legacy code depends on this working, compilers
> will generaly do whatever is necessary to make it work.
>
> You shouldn't need to cast ints to/from pointers anymore unless
> you need to enter absolute address or similar issues. (void*)
> can be assigned any data pointer the same way int used to be
> a universal pointer type.
The universal pointer type was never int - it was char * before it was
void *.
Mark McIntyre
<rgrile...@gmail.com> wrote:
>
>Did you read the OP?
Yes. So what?
>
(quoting me)
>> that most regulars will review code *in its entirety*, partly on the
>> (often correct) assumption that the OP may be completely mistaken
>> about the cause of their bug, partly out of kindness.
>
>The review of the code wasnt the issue. The question about casting was.
Did you actually read *and understand* what I wrote?
>> If you don't post the code that went wrong, how can someone diagnose
>> it? And if you want to post pseudocode, then say so.
>
>So you would have thought that "etc." was his code would you?
Of course not, don't be disingenuous, But either he copied a chunk of
his code, snipped it off at a certain point and wrote etc afterwards,
or he retyped the code from memory, which is in any events a horrible
idea.
>Why it takes so many people to police posters looking for help is
>foreign to me.
When you've been around usenet as long as I have, you will appreciate
topicality, and for what its worth, the posts in this thread were not
'policing' but advice.
SM Ryan
# The universal pointer type was never int - it was char * before it was
# void *.
Actually it was, and has been enshrined in APIs that have
been around for 30 years like yacc and yyparse(). Then it
became (char*) and then (void*).
--
SM Ryan http://www.rawbw.com/~wyrmwif/
I'm not even supposed to be here today.
Richard G. Riley
Q: isnt it common consensus in the C world that pointers are always the HW
word size of the underlying architecture? So, I'm still waiting for
one concreate example of where pointers to FP types are a different
size to pointer to ints. It might not be portable in terms of true C,
but for someone wanting to do something highly optimized it is a safe
assumption isnt it?
Barry Schwarz
<rgrile...@gmail.com> wrote:
>On 2006-02-22, Vladimir S. Oka <nov...@btopenworld.com> wrote:
>> Richard G. Riley wrote:
>>> On 2006-02-22, Vladimir S. Oka <nov...@btopenworld.com> wrote:
>>> >> etc.
>>> >
>>> > This is a syntax error.
>>>
>>> Well spotted. Go to top of the pedants class.
>>
>> Yes! I finally made it!
>>
>> Snipping relevant parts of the post is bad etiquette. I also said:
>>
>>> > Please post full, compileable, minimal examples.
>>
>> Which was the whole point. It's in the OP's interest, really.
>>
>
>The snipped part had no relevance on my pithy reply to your pedant
>prize winning reply. The guy was asking a question about casting : not for a
>code review or smart assed comments on "etc." being a syntx error.
Silly me. I thought the syntax error was t.whatever since t is a
pointer to struct. Maybe you don't think that was relevant either.
Remove del for email
Flash Gordon
<snip>
> implementation-defined. If the result cannot be represented
> in the integer type, the behavior is undefined. The result
> need not be in the range of values of any integer type.
but the implementation may define it as undefined (not integer type
large enough for any address). Or as undefined if the pointer happens to
be to an address outside a specific range (some pointers convert to
integers within the range of the largest integer type, so fo integers
outside the range), and of course there is no way to determine if the
address is within that range...
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc