pointer truncation from 'void *' to 'int'

[Alfonso Morra]

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

[Eric Lavigne]

>Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

You are worried about whether converting void* to int really involves
truncation? I am new to C, but it seems that sizeof would answer this
question for you. I imagine that the space required for pointers would
vary from one machine to another, depending on the total amount of
available memory, while the size of int would more likely just match
the IEEE recommendation.

[Alexei A. Frounze]

"Alfonso Morra" <sw***********@the-ring.com> wrote in message
news:dc**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Because sizeof(void*) doesn't necessarily equal to sizeof(int) nor
sizeof(void(*)()), it's all platform dependent (and sometimes even compiler
dependent). And, although a pointer is an integer address of a memory cell,
semantically its a very different type from an integer, so you shouldn't
expect the compiler eat your code and doesn't eructate.

Alex

[Flash Gordon]

Alfonso Morra wrote:

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
That, I believe, is a constraint violation, i.e. an error. There is also
no guarantee that even if you cast the value it will actually fit in an int.
Pointers are stored as ints (is that right?),
Wrong. Pointer are stored as pointers. These could be the same size as
ints, larger or smaller. Pointers to consecutive locations could also,
which converted to a suitable integer type, not be consecutive integers.
so as AFAIK, there is
nothing to worry about is there?
There is everything to worry about. Your program is wrong, non-portable,
and quite likely to break as soon as you try to compile for a 64 bit
target. There you could find (depending on the model used) that pointers
are 64 bits wide whilst int is only 32 bits wide, and there is no
guarantee that *any* integer type is wide enough.
I'm using VC 7.1

Why are such assignments being treated as errors?

Because they are errors. Whatever you are trying to do, you are almost
certainly doing it the wrong way.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Denis Kasak]

Alfonso Morra wrote:

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

There is no guarantee that pointers on your implementation are even
representable as int. Pointer to int conversion is implementation
defined and as such cannot be relied upon.

-- Denis

[Emmanuel Delahaye]

Alfonso Morra wrote on 24/07/05 :

I'm getting a compiler error of "pointer truncation from 'void *' to 'int'"
because I'm not explicitly casting from void* to (datatype*). Pointers are
stored as ints (is that right?),
Saiz who ? This statement is plain wrong. Pointers are stored as ...
pointers.
so as AFAIK, there is nothing to worry about
is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Because they are potential errors. In a 16 bit x386 machine, you can
have 16-int and 32-bit pointers.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Martin Ambuhl]

Alfonso Morra wrote:

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?),
Wrong. Pointers are stored as pointers.
so as AFAIK, there is
nothing to worry about is there?
Yes, there is.
I'm using VC 7.1

Why are such assignments being treated as errors?

Because they are erroneous.

[Charles F McDevitt]

"Alfonso Morra" <sw***********@the-ring.com> wrote in message
news:dc**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Altough the C standard doesn't say so, *most* (99.9%) of C implementations
have sizeof(long)==sizeof(void *),
so you can convert pointer to long and back again.

[Charles F McDevitt]

"Charles F McDevitt" <Ch************@comcast.net> wrote in message
news:ld********************@comcast.com...

"Alfonso Morra" <sw***********@the-ring.com> wrote in message
news:dc**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Altough the C standard doesn't say so, *most* (99.9%) of C implementations
have sizeof(long)==sizeof(void *),
so you can convert pointer to long and back again.

Oopss.. I means to say sizeof(long)>=sizeof(void *)

[Eric Sosman]

Charles F McDevitt wrote:

"Alfonso Morra" <sw***********@the-ring.com> wrote in message
news:dc**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Altough the C standard doesn't say so, *most* (99.9%) of C implementations
have sizeof(long)==sizeof(void *),

Balderdash.

Besides, what has sizeof got do do with it? If sizeof(void*)
happens to equal sizeof(float) or sizeof(double), what conclusion
can you draw about interconvertibility?

--
Eric Sosman
es*****@acm-dot-org.invalid

[Barry Schwarz]

On Sun, 24 Jul 2005 13:49:49 +0000 (UTC), Alfonso Morra
<sw***********@the-ring.com> wrote:

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Converting from void* to datatype* does not involve any integer
conversion. Furthermore, a cast is not necessary. Your assumption
about the cause of the error message is suspect.
Pointers are stored as ints (is that right?), so as AFAIK, there is
While the representation of a pointer value may coincide with the
representation of an integer value, the two types are completely
distinct. Pointers are stored in objects with type pointer to T and
integers are stored in objects with type int (or long or short, etc).
nothing to worry about is there?
If there was nothing to worry about, the compiler would probably not
be bringing it to your attention (though not universally true). In
this case, it definitely is something to worry about.

I'm using VC 7.1
Probably not relevant.

Why are such assignments being treated as errors?

You apparently did something unintended. Show us your code.
<<Remove the del for email>>

[Keith Thompson]

"Charles F McDevitt" <Ch************@comcast.net> writes:

"Charles F McDevitt" <Ch************@comcast.net> wrote in message
news:ld********************@comcast.com...

[...]

Altough the C standard doesn't say so, *most* (99.9%) of C implementations
have sizeof(long)==sizeof(void *),
so you can convert pointer to long and back again.

Oopss.. I means to say sizeof(long)>=sizeof(void *)

Which means you can write code that will fail mysteriously as soon as
it's ported to a system where sizeof(long) < sizeof(void*).

Or you can write portable code that will work on any platform.

The language allows conversions between pointers and integers, but
there's rarely any good reason to use such conversions. 99.9% of the
time, it's better just to treat pointers as pointers.

--
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.

[Keith Thompson]

"Alexei A. Frounze" <al*****@chat.ru> writes:

"Alfonso Morra" <sw***********@the-ring.com> wrote in message
news:dc**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Because sizeof(void*) doesn't necessarily equal to sizeof(int) nor
sizeof(void(*)()), it's all platform dependent (and sometimes even compiler
dependent). And, although a pointer is an integer address of a memory cell,
semantically its a very different type from an integer, so you shouldn't
expect the compiler eat your code and doesn't eructate.

No, a pointer is not necessarily an integer address of a memory cell.
It is on many systems, but the standard makes no such guarantee, and
there are real-world systems where the assumption breaks down.

--
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.

[Alexei A. Frounze]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
....

No, a pointer is not necessarily an integer address of a memory cell.
It is on many systems, but the standard makes no such guarantee, and
there are real-world systems where the assumption breaks down.

What is it then? Just give a few examples.

Alex

[Robert W Hand]

On Mon, 25 Jul 2005 00:00:17 +0400, "Alexei A. Frounze"
<al*****@chat.ru> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
...

No, a pointer is not necessarily an integer address of a memory cell.
It is on many systems, but the standard makes no such guarantee, and
there are real-world systems where the assumption breaks down.

What is it then? Just give a few examples.

In the old DOS 16-bit world, there were near and far pointers. Far
pointers had an offset added in, IIRC. It was possible for different
"integer" values to point to the same address.
--

Best wishes,

Bob

[Emmanuel Delahaye]

Alexei A. Frounze wrote on 24/07/05 :

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
...

No, a pointer is not necessarily an integer address of a memory cell.
It is on many systems, but the standard makes no such guarantee, and
there are real-world systems where the assumption breaks down.

What is it then? Just give a few examples.

How is 1234:4567 an integer ?

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

"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC

[Alexei A. Frounze]

"Robert W Hand" <rw****@NOSPAMoperamail.com> wrote in message
news:lq********************************@4ax.com...

On Mon, 25 Jul 2005 00:00:17 +0400, "Alexei A. Frounze"
<al*****@chat.ru> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
...

No, a pointer is not necessarily an integer address of a memory cell.
It is on many systems, but the standard makes no such guarantee, and
there are real-world systems where the assumption breaks down.

What is it then? Just give a few examples.

In the old DOS 16-bit world, there were near and far pointers. Far
pointers had an offset added in, IIRC. It was possible for different
"integer" values to point to the same address.

As Emmanuel suggested 0x1234:0x5678 :), I can agree it's not really a
number, at least when written like this (unless : represents division :).
But if we're really talking about converting real mode far pointers to
integers, the usual result of converting 0x1234:0x5678 to unsigned long
would be 0x12345678, which however does not represent directly a valid
(physical) address in the real mode address range, still is some number and
the backconversion is possible w/o loss of the info. OK, is there anything
else but the segmentation/page translation to consider? Something really
odd?

Alex

[Keith Thompson]

"Alexei A. Frounze" <al*****@chat.ru> writes:

"Robert W Hand" <rw****@NOSPAMoperamail.com> wrote in message
news:lq********************************@4ax.com...

On Mon, 25 Jul 2005 00:00:17 +0400, "Alexei A. Frounze"
<al*****@chat.ru> wrote:

>"Keith Thompson" <ks***@mib.org> wrote in message
>news:ln************@nuthaus.mib.org...
>...
>> No, a pointer is not necessarily an integer address of a memory cell.
>> It is on many systems, but the standard makes no such guarantee, and
>> there are real-world systems where the assumption breaks down.
>
>What is it then? Just give a few examples.

In the old DOS 16-bit world, there were near and far pointers. Far
pointers had an offset added in, IIRC. It was possible for different
"integer" values to point to the same address.

As Emmanuel suggested 0x1234:0x5678 :), I can agree it's not really a
number, at least when written like this (unless : represents division :).
But if we're really talking about converting real mode far pointers to
integers, the usual result of converting 0x1234:0x5678 to unsigned long
would be 0x12345678, which however does not represent directly a valid
(physical) address in the real mode address range, still is some number and
the backconversion is possible w/o loss of the info. OK, is there anything
else but the segmentation/page translation to consider? Something really
odd?

I seem to recall that pointers (at least function pointers) on the IBM
AS/400 are rather odd beasts. I don't know the details.

On Cray vector machines, word pointers are memory addresses (that look
like integers), but byte pointers have an offset in the high-order
bits. Code that attempts to treate pointers as integers fails.

--
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.

[Chris Torek]

In article <3k************@individual.net>
Alexei A. Frounze <al*****@chat.ru> wrote:

As Emmanuel suggested 0x1234:0x5678 :), I can agree it's not really a
number, at least when written like this (unless : represents division :).
But if we're really talking about converting real mode far pointers to
integers, the usual result of converting 0x1234:0x5678 to unsigned long
would be 0x12345678 ...
Unless you do it by computing the real physical address in memory,
in which case it is (0x1234 << 4) + 0x5678 = 0x179b8.
... [but] is there anything else but the segmentation/page translation
to consider? Something really odd?

There is always the IBM AS/400, with its 128-bit pointers, of which
many bits are reserved to the system.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Jack Klein]

On 24 Jul 2005 07:17:01 -0700, "Eric Lavigne" <la**********@gmail.com>
wrote in comp.lang.c:

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).
Pointers are stored as ints (is that right?), so as AFAIK, there is
nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

You are worried about whether converting void* to int really involves
truncation? I am new to C, but it seems that sizeof would answer this
question for you. I imagine that the space required for pointers would
vary from one machine to another, depending on the total amount of
available memory, while the size of int would more likely just match
the IEEE recommendation.

There is no IEEE standard that governs the size of an int in C, and
even if there were, it would not override the C standard.

There is one and only one requirements for the type int in C, and that
is it must be able to contain all values in the range of -32767 to
+32767.

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

[CBFalconer]

Keith Thompson wrote:

"Alexei A. Frounze" <al*****@chat.ru> writes:

"Alfonso Morra" <sw***********@the-ring.com> wrote in message

I'm getting a compiler error of "pointer truncation from 'void *'
to 'int'" because I'm not explicitly casting from void* to
(datatype*). Pointers are stored as ints (is that right?), so as
AFAIK, there is nothing to worry about is there?

I'm using VC 7.1

Why are such assignments being treated as errors?

Because sizeof(void*) doesn't necessarily equal to sizeof(int) nor
sizeof(void(*)()), it's all platform dependent (and sometimes even
compiler dependent). And, although a pointer is an integer address
of a memory cell, semantically its a very different type from an
integer, so you shouldn't expect the compiler eat your code and
doesn't eructate.

No, a pointer is not necessarily an integer address of a memory
cell. It is on many systems, but the standard makes no such
guarantee, and there are real-world systems where the assumption
breaks down.

I have watched this silly "discussion" go on for two days, or so,
an nobody seems to want to bother to tell the poor OP that he
failed to #include <stdlib.h>.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Alfonso Morra]

Barry Schwarz wrote:

On Sun, 24 Jul 2005 13:49:49 +0000 (UTC), Alfonso Morra
<sw***********@the-ring.com> wrote:

Hi,

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).

Converting from void* to datatype* does not involve any integer
conversion. Furthermore, a cast is not necessary. Your assumption
about the cause of the error message is suspect.

Pointers are stored as ints (is that right?), so as AFAIK, there is

While the representation of a pointer value may coincide with the
representation of an integer value, the two types are completely
distinct. Pointers are stored in objects with type pointer to T and
integers are stored in objects with type int (or long or short, etc).

nothing to worry about is there?

If there was nothing to worry about, the compiler would probably not
be bringing it to your attention (though not universally true). In
this case, it definitely is something to worry about.

I'm using VC 7.1

Probably not relevant.

Why are such assignments being treated as errors?

You apparently did something unintended. Show us your code.

Here is a snippet of one of the functions that causes the compiler to
barf (note the language is C++), but I'm not really doing anything C++
specific :
void *SharedMemory::Create(int memsize) {
SharedMemory::HEADER *p = NULL;

/* Code to alloc mem etc */
....
p = (SharedMemory::HEADER *) ((int)p + p->size); //offending line
....
}
<<Remove the del for email>>

[Richard Bos]

Alfonso Morra <sw***********@the-ring.com> wrote:

Here is a snippet of one of the functions that causes the compiler to
barf (note the language is C++), but I'm not really doing anything C++
specific :
Yes, you are. First of all, you're asking about void *s, which behave
differently in C and in C++; C++ sacrificed some usefulness for
theoretical (but not practical) type-safety. Second:
void *SharedMemory::Create(int memsize) { ^^
SharedMemory::HEADER *p = NULL; ^^
p = (SharedMemory::HEADER *) ((int)p + p->size); //offending line

^^
Richard

[Grumble]

Charles F McDevitt wrote:

Altough the C standard doesn't say so, *most* (99.9%) of C
implementations have sizeof(long)==sizeof(void *), so you
can convert pointer to long and back again.

Not really. MSVC on AMD64 has, AFAICT,
CHAR_BIT == 8
sizeof(long) == 4
sizeof(void *) == 8

http://www.microsoft.com/whdc/winhec.../64bitAMD.mspx

<quote>
Another bad bit of code casts a pointer to a long. Such code would run
properly on 32-bit Windows, but the pointer will get truncated when you
compile the code for 64-bit Windows.
</quote>

Do you claim the market share of Visual Studio on AMD64/EM64T is
less than 0.1 percent?

[Richard Bos]

Grumble <de*****@kma.eu.org> wrote:

Charles F McDevitt wrote:

Altough the C standard doesn't say so, *most* (99.9%) of C
implementations have sizeof(long)==sizeof(void *), so you
can convert pointer to long and back again.

Not really. MSVC on AMD64 has, AFAICT,
CHAR_BIT == 8
sizeof(long) == 4
sizeof(void *) == 8

http://www.microsoft.com/whdc/winhec.../64bitAMD.mspx

<quote>
Another bad bit of code casts a pointer to a long. Such code would run
properly on 32-bit Windows, but the pointer will get truncated when you
compile the code for 64-bit Windows.
</quote>

Guess where such behaviour is rife, and can hardly be avoided? Right,
the Windows API. Grumble.

Richard

[Eric Sosman]

Alfonso Morra wrote:

Here is a snippet of one of the functions that causes the compiler to
barf (note the language is C++), but I'm not really doing anything C++
specific :
Well, there's some dodgy syntax.
void *SharedMemory::Create(int memsize) {
SharedMemory::HEADER *p = NULL;

/* Code to alloc mem etc */
...
p = (SharedMemory::HEADER *) ((int)p + p->size); //offending line

Yes, that line offends. Not only is it offensive, but
it's dumb. Why rely on an unreliable implementation-defined
non-portable conversion when there's a reliable well-defined
fully portable alternative?

p = (SharedMemory::HEADER*) ((char*)p + p->size);

Shoving pointy sticks up my nose improves my disposition,
because it feels *so* good when I stop.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Steve Summit]

Alfonso Morra writes:

I'm getting a compiler error of "pointer truncation from 'void *' to
'int'" because I'm not explicitly casting from void* to (datatype*).

Here is a snippet of one of the functions that causes the compiler to
barf (note the language is C++), but I'm not really doing anything C++
specific :

As Richard has already pointed out, those :: namespace operators
indicate that you certainly *are* doing something C++ specific!
SharedMemory::HEADER *p = NULL;
/* Code to alloc mem etc */
p = (SharedMemory::HEADER *) ((int)p + p->size); //offending line

What in the world are you trying to do here?! You're taking a
null pointer, casting it to an int, adding (I presume) another
int to it, and then trying to cast the result back to a pointer.
Moreover, unless I'm missing something, the int you're adding in
(that is, p->size) is fetched off of the null pointer you started
with. This doesn't look like it'll do anything useful, and it
*certainly* doesn't look like it'll allocate any memory!

I'm not sure I would have expected the compiler's first complaint
here to be about truncation of void * to int (in particular,
there aren't any void pointers in sight), but I'm glad it
complained about something, because you definitely need to
reexamine your thinking.

(There's an old rule, and it certainly applies here, that casts
should be used sparingly, and only when you know what you're
doing, and certainly not willy-nilly just to shut the compiler
up. In particular, you don't allocate memory by casting an int
to a pointer; you've got to call a memory-allocation function
somewhere! When the compiler complains about attempted
int-to-pointer conversions, and unless you're writing low-level
pointer manipulation code of the sort that only a linker ought to
be doing, the complaint almost invariably indicates that you're
mixing apples and oranges in an irreconciliable way, which the
insertion of a bunch of casts will only make worse.)

If the comment "Code to alloc mem etc" replaces some explicit
memory-allocation logic that is in your actual code; if p has
been appropriately set up to point at a SharedMemory::HEADER
object by the time you hit the line

p = (SharedMemory::HEADER *) ((int)p + p->size);

the problem may simply be that (int) cast, which is truncating a
pointer into an int (though the pointer it's truncating is a
SharedMemory::HEADER *, not a void *). What happens if you
remove both casts? That is, what happens if you use the
straightforward

p = p + p->size;

instead? That's normal-looking pointer arithmetic, and is
probably closer to what you want. The explicit casts make me
suspect that at some point you were either (a) trying to do the
pointer arithmetic in chunks of other than sizeof(SharedMemory::HEADER),
or (b) using void pointers which the compiler (correctly) wouldn't
let you do arithmetic on at all.

Steve Summit
sc*@eskimo.com