integer to pinter conversion

[junky_fellow]

Consider a function:

void *test_func(void)
{
return ((void *)-1);
}

While returning, the integer -1 is converted to void *.
Is this portable ?

[Irrwahn Grausewitz]

ju**********@yahoo.co.in wrote:

Consider a function:

void *test_func(void)
{
return ((void *)-1);
}

While returning, the integer -1 is converted to void *.
Is this portable ?

No. While an integer may be converted to a pointer, the result
of this conversion is implementation-defined, with the obvious
exception of an integer constant expression with the value 0.

FWIW, you don't even need the cast in the code above.

Best regards.
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc

[pete]

ju**********@yahoo.co.in wrote:

Consider a function:

void *test_func(void)
{
return ((void *)-1);
}

While returning, the integer -1 is converted to void *.
Is this portable ?

No.

--
pete

[junky_fellow]

Irrwahn Grausewitz wrote:

ju**********@yahoo.co.in wrote:

Consider a function:

void *test_func(void)
{
return ((void *)-1);
}

While returning, the integer -1 is converted to void *.
Is this portable ?

No. While an integer may be converted to a pointer, the result
of this conversion is implementation-defined, with the obvious
exception of an integer constant expression with the value 0.

FWIW, you don't even need the cast in the code above.

Is the conversion of integer to pointer and back again (pointer to
integer) will give the original integer ?

[Irrwahn Grausewitz]

ju**********@yahoo.co.in wrote:

Irrwahn Grausewitz wrote:

ju**********@yahoo.co.in wrote:

>Consider a function:
>
>void *test_func(void)
>{
> return ((void *)-1);
>}
>
>While returning, the integer -1 is converted to void *.
>Is this portable ?

No. While an integer may be converted to a pointer, the result
of this conversion is implementation-defined, with the obvious
exception of an integer constant expression with the value 0.

FWIW, you don't even need the cast in the code above.

Is the conversion of integer to pointer and back again (pointer to
integer) will give the original integer ?

I can't find any such guarantee in the standard, so I'd say: no.

IMO, if you feel the need to convert pointers to ints and vice versa,
your program logic is broken.

Best regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc

[Lawrence Kirby]

On Wed, 14 Sep 2005 01:19:36 -0700, junky_fellow wrote:

Irrwahn Grausewitz wrote:

ju**********@yahoo.co.in wrote:

>Consider a function:
>
>void *test_func(void)
>{
> return ((void *)-1);
>}
>
>While returning, the integer -1 is converted to void *.
>Is this portable ?
No. While an integer may be converted to a pointer, the result
of this conversion is implementation-defined, with the obvious
exception of an integer constant expression with the value 0.

FWIW, you don't even need the cast in the code above.

Yes, you do, the only integer calues that can be converted to pointer
types without a cast are null pointer constants, and -1 isn't one of those.
Is the conversion of integer to pointer and back again (pointer to
integer) will give the original integer ?

No, converting an integer to a pointer can result in a trap
representation. In which case just looking at the value will cause
undefined behaviour.

Lawrence

[Irrwahn Grausewitz]

Lawrence Kirby <lk****@netactive.co.uk> wrote:

Irrwahn Grausewitz wrote:

ju**********@yahoo.co.in wrote:
>Consider a function:
>
>void *test_func(void)
>{
> return ((void *)-1);
>}
>
>While returning, the integer -1 is converted to void *.
>Is this portable ?

No. While an integer may be converted to a pointer, the result
of this conversion is implementation-defined, with the obvious
exception of an integer constant expression with the value 0.

FWIW, you don't even need the cast in the code above.

Yes, you do, the only integer calues that can be converted to pointer
types without a cast are null pointer constants, and -1 isn't one of those.

<snip>

Oops, you're right, I forgot about assignment constraints.

Best regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc

[Walter Roberson]

In article <11*********************@g49g2000cwa.googlegroups. com>,
<ju**********@yahoo.co.in> wrote:

Is the conversion of integer to pointer and back again (pointer to
integer) will give the original integer ?

KR2 promises that it will [provided the sizes are compatable], but
C89 does NOT have that guarantee.

In the simplest case: conversion of the integer constant 0 to
a pointer results in the "null pointer constant", which is NOT certain to
be all-zeroes internally. Converting the null pointer constant
to an integer is not defined as returning 0.

Furthermore, C89 allows for the possibility that a null pointer
constant, when converted to pointer type other than void *, might take
on a different value, not necessarily the same for each type. Converting
that back to void * is not certain to result in a bit pattern which
is the same as the canonical null pointer constant: it is only
certain that no matter what sequence of pointer conversions one
undertakes, that all null pointers will compare equal.

--
Entropy is the logarithm of probability -- Boltzmann

[SM Ryan]

ju**********@yahoo.co.in wrote:
# Consider a function:
#
# void *test_func(void)
# {
# return ((void *)-1);
# }
#
# While returning, the integer -1 is converted to void *.
# Is this portable ?

The code is portable. What it means depends on the system.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I think that's kinda of personal; I don't think I should answer that.

[Irrwahn Grausewitz]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

ju**********@yahoo.co.in wrote:
#
# void *test_func(void)
# {
# return ((void *)-1);
# }
#
# While returning, the integer -1 is converted to void *.
# Is this portable ?

The code is portable.
Nope, it's not portable. Well, unless you refer to portable as in
beer, not in programming: you can print it out and carry it around.
By that definition, all code is portable.
What it means depends on the system.

Three very popular meanings:
1. You shoot yourself in the foot.
2. You shoot yourself in the foot, but don't notice.
3. You shoot yourself in someone else's foot.

Best regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc

[Jack Klein]

On Wed, 14 Sep 2005 09:37:14 +0200, Irrwahn Grausewitz
<ir*******@freenet.de> wrote in comp.lang.c:

ju**********@yahoo.co.in wrote:

Consider a function:

void *test_func(void)
{
return ((void *)-1);
}

While returning, the integer -1 is converted to void *.
Is this portable ?

No. While an integer may be converted to a pointer, the result
of this conversion is implementation-defined, with the obvious
exception of an integer constant expression with the value 0.

FWIW, you don't even need the cast in the code above.

I beg to differ. With the exception of an integer constant expression
evaluating to 0 (i.e., special case to initialize/set a pointer to
NULL), a cast is required to convert between an integer type and a
pointer type. Regardless of whether that is in an initialization,
assignment, or passing as a parameter or returning. The latter two
are performed "as if by assignment" anyway.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Christopher Benson-Manica]

Irrwahn Grausewitz <ir*******@freenet.de> wrote:

IMO, if you feel the need to convert pointers to ints and vice versa,
your program logic is broken.

I would say "broken" only from the point of view of the Standard; many
nonconforming programs make use of such conversions quite
successfully. I do agree that it isn't the best possible design
choice.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Keith Thompson]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

Irrwahn Grausewitz <ir*******@freenet.de> wrote:

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

ju**********@yahoo.co.in wrote:
>
> void *test_func(void)
> {
> return ((void *)-1);
> }
>
> While returning, the integer -1 is converted to void *.
> Is this portable ?

The code is portable.

Nope, it's not portable. Well, unless you refer to portable as in

Whine to X3 committee of ANSI then. X3.159-1989, section 3.3.4

An arbitrary integer may be converted to a pointer.
The result is implementation defined.

Sounds portable to me.

[ Deliberately obnoxious quoting character corrected *yet again*. ]

Note the distinction between "implementation defined" and "portable".
The code is portable in that it's legal on all implementations, but
it's not guaranteed to do what you want.

Presumably ((void*)-1) is intended to be a unique pointer value that
doesn't necessarily point to any object, basically a secondary null
pointer value. The standard doesn't guarantee that this value is
actually unique. It's possible, though unlikely, that it could happen
to be equal to some valid pointer value. It could even be equal to
NULL.

And that's assuming that the conversion from int to void* behaves
sensibly. That's usually a safe assumption, but the standard doesn't
guarantee it. The only real guarantee about pointer/integer
conversions is that converting a void* to intptr_t or uintptr_t and
back again yields the original value, *if* intptr_t exists; even
changing -1 to (intptr_t)-1 doesn't take advantage of this, since -1
wasn't obtained by converting a void* value.

It's likely to work just fine on most or all real-world
implementations -- or it could break mysteriously when it's ported to
a new platform, forcing you to waste a week or two tracking down the
cause of the misbehavior.

And it's all unnecessary. If you want a unique void* value other than
null, just declare an unused object and take its address:

static int hidden_object;
#define ERROR_INDICATOR (void*)&hidden_object

This has the added benefit of giving a meaningful name to the unique
value, rather than inducing future maintainers to repeat this very
argument.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Irrwahn Grausewitz]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Irrwahn Grausewitz <ir*******@freenet.de> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
# >ju**********@yahoo.co.in wrote:
# >#
# ># void *test_func(void)
# ># {
# ># return ((void *)-1);
# ># }
# >#
# ># While returning, the integer -1 is converted to void *.
# ># Is this portable ?
# >
# >The code is portable.
#
# Nope, it's not portable. Well, unless you refer to portable as in

Whine to X3 committee of ANSI then. X3.159-1989, section 3.3.4

An arbitrary integer may be converted to a pointer.
The result is implementation defined.
C99 6.3.2.3p5
An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined,
might not be correctly aligned, might not point to an entity of
the referenced type, and might be a trap representation.

["Except as previously specified" refers to the well-defined
and portable conversion of an integer constant expression with
the value 0 to a pointer.]
Sounds portable to me.
But it means the exact opposite: if you run across "the result is
implementation defined" in the standard, that effectively means: it's
not portable; you may use it, but be aware that the result might
differ from system to system, or compiler version to compiler version.
As others already pointed out, the result might equal NULL, or a
pointer to an actual object, or even be a trap representation.
# Three very popular meanings:
# 1. You shoot yourself in the foot.
# 2. You shoot yourself in the foot, but don't notice.
# 3. You shoot yourself in someone else's foot.

Since Unix does this, you are claiming Unix is not a popular system?

You missed the invisible smiley.

Best regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc

[Simon Biber]

Kenneth Brody wrote:

Chris Dollin wrote:

SM Ryan wrote:

Irrwahn Grausewitz <ir*******@freenet.de> wrote:
# Nope, it's not portable. Well, unless you refer to portable as in

Whine to X3 committee of ANSI then. X3.159-1989, section 3.3.4

An arbitrary integer may be converted to a pointer.
The result is implementation defined.

Sounds portable to me.

"The result is implementation defined" doesn't sound portable to
*me*; it can vary between implementations in some fashion not
predictable (from the standard).

I guess it depends what is going to be done with that value. If it
will be compared to "((void *)-1)" to signal some special condition
other than success or NULL, won't that work regardless of what is the
actual "implementation defined" behavior?

No! Consider an implementation where all-bits-one is a representation of
a null pointer. (void*)-1 may compare equal to NULL.

A sufficiently perverse implementation may make all integers, when
converted to a pointer, become null pointers.

--
Simon.

[Emmanuel Delahaye]

ju**********@yahoo.co.in wrote on 14/09/05 :

Is the conversion of integer to pointer and back again (pointer to
integer) will give the original integer ?

Yes, no. It's implementation-dependent.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

[Emmanuel Delahaye]

Irrwahn Grausewitz wrote on 14/09/05 :

IMO, if you feel the need to convert pointers to ints and vice versa,
your program logic is broken.

I would have said "it probably denotes a design error".

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

[SM Ryan]

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote:
# Irrwahn Grausewitz wrote on 14/09/05 :
# > IMO, if you feel the need to convert pointers to ints and vice versa,
# > your program logic is broken.
#
# I would have said "it probably denotes a design error".

I'm sure programmers who write device drivers and operating systems
shall be enlightenned by your instruction.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
The little stoner's got a point.

[Alexei A. Frounze]

"SM Ryan" <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote in
message news:11*************@corp.supernews.com...

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote: .... # I would have said "it probably denotes a design error".

I'm sure programmers who write device drivers and operating systems
shall be enlightenned by your instruction.

Quite true. :) But OSes themselves are normally designed to run on a
particular CPU/hardware and don't have to exhibit the kind of portability
the applications should. This is the distinction to keep in mind.

Alex

[Kenneth Brody]

Simon Biber wrote:
[... ((void *)-1) portability ...]

I guess it depends what is going to be done with that value. If it
will be compared to "((void *)-1)" to signal some special condition
other than success or NULL, won't that work regardless of what is the
actual "implementation defined" behavior?

No! Consider an implementation where all-bits-one is a representation of
a null pointer. (void*)-1 may compare equal to NULL.

A sufficiently perverse implementation may make all integers, when
converted to a pointer, become null pointers.

"Why did you design it that way?"
"Because the Standard says I can!"
Of course, "(void *)-1" will still compare equal to "(void *)-1", won't
it? :-)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Joe Wright]

SM Ryan wrote:

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote:
# Irrwahn Grausewitz wrote on 14/09/05 :
# > IMO, if you feel the need to convert pointers to ints and vice versa,
# > your program logic is broken.
#
# I would have said "it probably denotes a design error".

I'm sure programmers who write device drivers and operating systems
shall be enlightenned by your instruction.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
The little stoner's got a point.

SM, in the normal course of events, your signature should not appear in
this reply to your post. This because a normal newsreader will read the
line above the sig and if it is "-- " ignore the rest for the reply.
Yours is "--" and missing the space. It is therefore included in the
reply. Can you change this?

I've never written a device driver in C nor have I had the chance to
write any OS code in C. I have written all kinds of other stuff in C and
I don't remember ever having to convert pointers and ints back and
forth. Why would I have to do that?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Eric Sosman]

Joe Wright wrote On 09/19/05 19:39,:

I've never written a device driver in C nor have I had the chance to
write any OS code in C. I have written all kinds of other stuff in C and
I don't remember ever having to convert pointers and ints back and
forth. Why would I have to do that?

One likely reason is memory management: You may find
that you need to decompose a pointer into multiple parts
and treat them differently. For example, you might need
to determine the "memory page" a pointer refers to and
arrange for that page to be locked in physical memory
for the duration of an I/O operation. On typical systems,
you'd do this by converting the pointer to some kind of
integer and then masking or shifting to separate "page"
from "offset."

Less system-dependent circumstances also arise. For
example, consider the job of implementing malloc() and its
associates (we are supposing that you're now acting as a
C implementor rather than a C user). One requirement on
malloc() is that it must return a pointer suitably aligned
for any data type. If your malloc() obtains memory from a
system service that doesn't guarantee alignment -- Unix'
sbrk(), for example -- you will need a way to inspect the
alignment characteristics of the addresses you receive.
Again, this is usually done by converting the address to
an integer and fiddling with the bits.

However, in user-level code it is quite rare that one
needs to convert pointers to and from integers. I'm not
saying that it's rarely done, just that it's rarely needed.

--
Er*********@sun.com

[Joe Wright]

Eric Sosman wrote:

Joe Wright wrote On 09/19/05 19:39,:

I've never written a device driver in C nor have I had the chance to
write any OS code in C. I have written all kinds of other stuff in C and
I don't remember ever having to convert pointers and ints back and
forth. Why would I have to do that?

One likely reason is memory management: You may find
that you need to decompose a pointer into multiple parts
and treat them differently. For example, you might need
to determine the "memory page" a pointer refers to and
arrange for that page to be locked in physical memory
for the duration of an I/O operation. On typical systems,
you'd do this by converting the pointer to some kind of
integer and then masking or shifting to separate "page"
from "offset."

Less system-dependent circumstances also arise. For
example, consider the job of implementing malloc() and its
associates (we are supposing that you're now acting as a
C implementor rather than a C user). One requirement on
malloc() is that it must return a pointer suitably aligned
for any data type. If your malloc() obtains memory from a
system service that doesn't guarantee alignment -- Unix'
sbrk(), for example -- you will need a way to inspect the
alignment characteristics of the addresses you receive.
Again, this is usually done by converting the address to
an integer and fiddling with the bits.

However, in user-level code it is quite rare that one
needs to convert pointers to and from integers. I'm not
saying that it's rarely done, just that it's rarely needed.

Thanks for the reply. I understand now.

<OT>
Out of curiosity, did you manage to have anything at all to do with
Galaxy? I can't imagine Scott thinking all this up or going along with
it but, as I can understand what's going on, it's absolutely brilliant.
Not only is it an answer to HP and IBM with their Intel stuff, Galaxy
AMD is clearly superior.

Go Sun!
</OT>
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---