pointer truncation from 'void *' to 'int'

A

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

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

Flash Gordon

Alfonso said:
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.
 
D

Denis Kasak

Alfonso said:
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
 
A

Alexei A. Frounze

Alfonso Morra said:
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
 
E

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

Martin Ambuhl

Alfonso said:
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.
 
C

Charles F McDevitt

Alfonso Morra said:
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.
 
C

Charles F McDevitt

Charles F McDevitt said:
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 *)
 
E

Eric Sosman

Charles said:
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?
 
B

Barry Schwarz

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

Keith Thompson

Charles F McDevitt said:
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.
 
K

Keith Thompson

Alexei A. Frounze said:
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.
 
A

Alexei A. Frounze

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

Robert W Hand

...

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

Alexei A. Frounze

Robert W Hand said:
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
 
K

Keith Thompson

Alexei A. Frounze said:
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.
 
C

Chris Torek

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

Jack Klein

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.
 

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

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top