Casting a pointer to an int and back

M

Mark McIntyre

Did you read the OP?

Yes. So what?
(quoting me)

The review of the code wasnt the issue. The question about casting was.

Did you actually read *and understand* what I wrote?
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.

Mark McIntyre
 
S

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*).
 
R

Richard G. Riley

# 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*).

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?
 
B

Barry Schwarz

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
 
F

Flash Gordon

pete said:
Richard said:
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.

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,278
Latest member
BuzzDefenderpro

Latest Threads

Top