Casting from pointer types to non-pointer types

[jois.de.vivre]

I am interfacing with a third party API (written in C, if that
matters) that has an "event handler" function with the following
definition:

void event_handler(i nt event_code, unsigned long user_data);

The function takes an event code along with the user data but does not
act on or change the user data.
In my application, I want to pass a pointer as the user data. This
pointer is to an array allocated with new, say, as follows:

char *array = new char[100];

and passed to the event handler as follows:

event_handler(1 , reinterpret_cas t<unsigned long>(array));

My question is if it's safe to cast this to an unsigned long type if I
want to reuse it later? Specifically will doing something like this
cause me any trouble?

void some_function(u nsigned long pointer)
{
char *array = reinterpret_cas t<char*>(pointe r);
/* do stuff with array */
delete [] array;
}

On my machine both sizeof(char*) and sizeof(unsigned long) is 8 so
while this is a pretty ugly solution, at first glance it would seem
safe (at least from overflow).

[Victor Bazarov]

jo***********@g mail.com wrote:

I am interfacing with a third party API (written in C, if that
matters) that has an "event handler" function with the following
definition:

void event_handler(i nt event_code, unsigned long user_data);

The function takes an event code along with the user data but does not
act on or change the user data.
In my application, I want to pass a pointer as the user data. This
pointer is to an array allocated with new, say, as follows:

char *array = new char[100];

and passed to the event handler as follows:

event_handler(1 , reinterpret_cas t<unsigned long>(array));

My question is if it's safe to cast this to an unsigned long type if I
want to reuse it later? Specifically will doing something like this
cause me any trouble?

It is safe and well-defined _if_ 'unsigned long' has the same size as
the pointer to which you're casting it.

>
void some_function(u nsigned long pointer)
{
char *array = reinterpret_cas t<char*>(pointe r);
/* do stuff with array */
delete [] array;
}

On my machine both sizeof(char*) and sizeof(unsigned long) is 8 so
while this is a pretty ugly solution, at first glance it would seem
safe (at least from overflow).

It is.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jacek Dziedzic]

jo***********@g mail.com wrote:

I am interfacing with a third party API (written in C, if that
matters) that has an "event handler" function with the following
definition:

void event_handler(i nt event_code, unsigned long user_data);

The function takes an event code along with the user data but does not
act on or change the user data.
In my application, I want to pass a pointer as the user data. This
pointer is to an array allocated with new, say, as follows:

char *array = new char[100];

and passed to the event handler as follows:

event_handler(1 , reinterpret_cas t<unsigned long>(array));

My question is if it's safe to cast this to an unsigned long type if I
want to reuse it later? Specifically will doing something like this
cause me any trouble?

void some_function(u nsigned long pointer)
{
char *array = reinterpret_cas t<char*>(pointe r);
/* do stuff with array */
delete [] array;
}

On my machine both sizeof(char*) and sizeof(unsigned long) is 8 so
while this is a pretty ugly solution, at first glance it would seem
safe (at least from overflow).

I think it would be "generally unsafe", but if your unsigned longs
really are 8 byte, then it will work. Still, an assert() that
sizeof(unsigned long)==sizeof(c har*) somewhere in your code
won't hurt (and it will help others in 20 years' time track
the bug as they port your code to machines using "__further" ,
16-byte pointers :>).

HTH,
- J.

[gaojb]

It should be safe. I believe in all current compiler, long and pointer
have same size. Please google "LP64" for more information.

[Thomas J. Gritzan]

Please quote some context. See my signature.

ga***@yahoo.com wrote:

It should be safe. I believe in all current compiler, long and pointer
have same size. Please google "LP64" for more information.

Not safe.
On a 64bit Windows system, a pointer has 64bit, but long has 32bit like an int.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[Victor Bazarov]

ga***@yahoo.com wrote:

It should be safe. I believe in all current compiler, long and pointer
have same size. Please google "LP64" for more information.

Win64 - BAM! - Pointers are 64 bit and longs are 32 bit.

[jois.de.vivre]

On Jun 6, 12:13 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

jois.de.vi...@g mail.com wrote:

I am interfacing with a third party API (written in C, if that
matters) that has an "event handler" function with the following
definition:

void event_handler(i nt event_code, unsigned long user_data);

The function takes an event code along with the user data but does not
act on or change the user data.
In my application, I want to pass a pointer as the user data. This
pointer is to an array allocated with new, say, as follows:

char *array = new char[100];

and passed to the event handler as follows:

event_handler(1 , reinterpret_cas t<unsigned long>(array));

My question is if it's safe to cast this to an unsigned long type if I
want to reuse it later? Specifically will doing something like this
cause me any trouble?

It is safe and well-defined _if_ 'unsigned long' has the same size as
the pointer to which you're casting it.

void some_function(u nsigned long pointer)
{
char *array = reinterpret_cas t<char*>(pointe r);
/* do stuff with array */
delete [] array;
}

On my machine both sizeof(char*) and sizeof(unsigned long) is 8 so
while this is a pretty ugly solution, at first glance it would seem
safe (at least from overflow).

It is.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

If the sizes differ, will the cast fail with a "loses precision"
error, such as attempting to cast from a pointer to say, an int?

char *array = new char[100];
int ptr_val = reinterpret_cas t<int>(array);

on gcc:
error: cast from 'char*' to 'int' loses precision

not sure if this is true with all compilers ...

[Victor Bazarov]

jo***********@g mail.com wrote:

[..]
If the sizes differ, will the cast fail with a "loses precision"
error, such as attempting to cast from a pointer to say, an int?

The Standard doesn't say what error message will be displayed. It
is up to the implementation.

char *array = new char[100];
int ptr_val = reinterpret_cas t<int>(array);

on gcc:
error: cast from 'char*' to 'int' loses precision

not sure if this is true with all compilers ...

It is not.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jim Langston]

<jo***********@ gmail.comwrote in message
news:11******** **************@ o11g2000prd.goo glegroups.com.. .

>I am interfacing with a third party API (written in C, if that
matters) that has an "event handler" function with the following
definition:

void event_handler(i nt event_code, unsigned long user_data);

The function takes an event code along with the user data but does not
act on or change the user data.
In my application, I want to pass a pointer as the user data. This
pointer is to an array allocated with new, say, as follows:

char *array = new char[100];

and passed to the event handler as follows:

event_handler(1 , reinterpret_cas t<unsigned long>(array));

My question is if it's safe to cast this to an unsigned long type if I
want to reuse it later? Specifically will doing something like this
cause me any trouble?

void some_function(u nsigned long pointer)
{
char *array = reinterpret_cas t<char*>(pointe r);
/* do stuff with array */
delete [] array;
}

On my machine both sizeof(char*) and sizeof(unsigned long) is 8 so
while this is a pretty ugly solution, at first glance it would seem
safe (at least from overflow).

Are you sure you are doing what you think you are doing?

array is a char pointer. It contains the address of the 100 characters that
new allocated. Your reinterpret_cas t<unsigned long>( array ) is
reinterpreting this *pointer* to an integer. I suspect you actually wanted
to use the buffer itself to hold the integer. Am I correct?

This program for one run on my system outputs:
4
3288656

Which is it you wanted to use? Notes follow the code.

#include <iostream>

void event_handler(i nt event_code, unsigned long user_data)
{
std::cout << user_data << "\n";
}

int main()
{
char *array = new char[100];

array[0] = 4;
array[1] = 0;
array[2] = 0;
array[3] = 0;
array[4] = 0;
array[5] = 0;
array[6] = 0;
array[7] = 0;

event_handler(1 , *reinterpret_ca st<unsigned long*>( array ));
event_handler(1 , reinterpret_cas t<unsigned long>( array ));

return 0;
}

This can be dangerous on some systems (treating the contents of some other
type as an integer) becasue of byte alignment. On some systems if an
integer is not correctly byte aligned the program can run slower,
malfunction or crash. Generally a integral type needs to be aligned on it's
size. A 4 byte integer on a byte evenly divisible by 4. An 8 byte integer
on a byte evenly divisible by 8, etc... So in that case, if you need to use
the buffer itself as the integer, it may not be safe depending on your
platform.

Notice how I'm passing the *contents* of the buffer as an unsigned long. I
cast the char pointer to an unsigned long pointer, then derefence it (asking
for it's contents).

[James Kanze]

On Jun 6, 10:28 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

jois.de.vi...@g mail.com wrote:

[..]
If the sizes differ, will the cast fail with a "loses precision"
error, such as attempting to cast from a pointer to say, an int?

The Standard doesn't say what error message will be displayed. It
is up to the implementation.

char *array = new char[100];
int ptr_val = reinterpret_cas t<int>(array);

on gcc:
error: cast from 'char*' to 'int' loses precision

not sure if this is true with all compilers ...

It is not.

Are you sure. According to the standard, "A pointer can be
explicitly converted to any integral type large enough to hold
it." (From the section on reinterpret_cas t.) Converting a
pointer to an integral type which is not large enough to hold it
cannot be done using reinterpret_cas t. A compiler is required
to emit a diagnostic.

According to the C++ standard, the same thing holds for a C
style cast. In C, however, it is undefined behavior, and
C compilers historically have supported it, so that I expect a
lot of C++ compilers will accept it unless you request strict
conformance. Both Sun CC and g++ give an error regardless of
the type of cast, in default mode. Using a C-style cast in C
provokes a warning from gcc, and nothing from Sun cc, however.
This is a point where the two languages differ.

The other direction is fine, however, and there is no problem
using reinterpret_cas t to convert a char to a pointer.

In the case in question, the poster needed a round trip
conversion pointer to integral type back to pointer. This
obviously can only work if the integral type is large enough.
Most of the time, however, it is the reverse that is needed; the
de facto standard "user data" type is void*, and if all you need
is a char... char->void*->char is forbidden by the standard, you
have to use char->void*->intptr_t->char. (And if the system
doesn't have an intptr_t, then you're out of luck.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]