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]

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.

 

[pete]

Consider a function:

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

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

No.

 

[junky_fellow]

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]

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]

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

 

[Lawrence Kirby]

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

 

[Walter Roberson]

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.

 

[SM Ryan]

(e-mail address removed) 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.

 

[Irrwahn Grausewitz]

(e-mail address removed) 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

 

[Jack Klein]

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.

 

[junky_fellow]

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.

Since the return type is void *, so if the function func() returns
-1, will the compiler not convert the integer to void * even if
the cast is not applied ? I get a warning without the cast, but the
conversion is still being done.

 

[SM Ryan]

# >[email protected] 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.

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

 

[Lawrence Kirby]

....


Since the return type is void *, so if the function func() returns
-1, will the compiler not convert the integer to void * even if
the cast is not applied ?

Trying to convert any integer value except a null pointer constant to a
pointer type without using a cast is a constraint violation. That is about
as severe a problem as you can get, on the same level as a syntax error.
IOW code that does that isn't valid C code.

I get a warning without the cast, but the
conversion is still being done.

All the standard requires is a diagnostic from the compiler and a warning
meets that requirement. What the compiler chooses to do beyond that e.g.
abort compiling or continue is entirely up to it and what the compiler
designer feels is appropriate.

Lawrence

 

[Chris Dollin]

Irrwahn Grausewitz <[email protected]> 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).

 

[Denis Kasak]

(e-mail address removed) 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.

I beg to differ. Your two sentences contradict themselves. If a piece of
code has different meanings on different platforms then it's not
portable. Relying on non-portable things can change or break the
behaviour of a program on different platforms. This is exactly how
integer to pointer conversion behaves. How is that portable?

-- Denis

 

[Kenneth Brody]

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

On the other hand, I suppose it's possible that the resulting pointer
happens to be valid in some circumstances, and you may end up with the
function returning a valid pointer only to be thought of as the invalid
one.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[SM Ryan]

# SM Ryan 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).

The result of fopen is implementation defined. Does that mean no
portable program is allowed to do I/O?

When you find yourself in a hole, stop digging.

 

[SM Ryan]

# SM Ryan wrote:
# > (e-mail address removed) 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.
#
# I beg to differ. Your two sentences contradict themselves. If a piece of

Only in your imagination. ANSI C does not provide detailed
mandatory semantics, or it would never get out of X3. Use
fopen to create a file in a hot folder and it can trigger
any possible activity for that system. All ANSI C can specify
is that if the system allows the file to be open, you get
back a FILE* that can be used in subsequent write functions.

ANSI C doesn't give semantics of real rational operator beyond
appeals to common sense notions of addition, subtraction,
multiplication, and division. Would you regard any program
that uses float or double to be nonportable?

 

[Christopher Benson-Manica]

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.