Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23969 > unrolled thread

casting unsigned int to void*

Back to article view | Back to comp.lang.c

Contents

  casting unsigned int to void* Fred K <fred.l.kleinschmidt@gmail.com> - 2012-07-30 10:33 -0700
    Re: casting unsigned int to void* Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-30 13:59 -0400
      Re: casting unsigned int to void* falk@rahul.net (Edward A. Falk) - 2012-07-30 19:03 +0000
    Re: casting unsigned int to void* James Kuyper <jameskuyper@verizon.net> - 2012-07-30 14:14 -0400
      Re: casting unsigned int to void* Fred K <fred.l.kleinschmidt@gmail.com> - 2012-07-30 11:23 -0700
        Re: casting unsigned int to void* pacman@kosh.dhis.org (Alan Curry) - 2012-07-30 18:46 +0000
          Re: casting unsigned int to void* Fred K <fred.l.kleinschmidt@gmail.com> - 2012-07-30 12:09 -0700
            Re: casting unsigned int to void* Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-30 21:02 +0100
    Re: casting unsigned int to void* bartek szurgot <basz@no.spam> - 2012-07-30 20:47 +0200
    Re: casting unsigned int to void* "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-30 13:04 -0700
      Re: casting unsigned int to void* James Kuyper <jameskuyper@verizon.net> - 2012-07-30 16:22 -0400
        Re: casting unsigned int to void* "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-30 14:55 -0700
          Re: casting unsigned int to void* James Kuyper <jameskuyper@verizon.net> - 2012-07-30 18:15 -0400
            Re: casting unsigned int to void* "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-30 15:18 -0700
              Re: casting unsigned int to void* Mark Bluemel <mark_bluemel@pobox.com> - 2012-07-31 08:30 +0100
                Re: casting unsigned int to void* "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-31 01:17 -0700
      Re: casting unsigned int to void* Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-30 23:36 +0100
      Re: casting unsigned int to void* Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-30 20:45 -0400
        Re: casting unsigned int to void* James Kuyper <jameskuyper@verizon.net> - 2012-07-31 07:23 -0400
    Re: casting unsigned int to void* Keith Thompson <kst-u@mib.org> - 2012-07-30 16:28 -0700
    Re: casting unsigned int to void* James Kuyper <jameskuyper@verizon.net> - 2012-07-31 07:26 -0400
      Re: casting unsigned int to void* 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-05 09:16 -0700
        Re: casting unsigned int to void* Ike Naar <ike@sdf.lonestar.org> - 2012-08-05 20:50 +0000
          Re: casting unsigned int to void* Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-08-10 11:05 +0300

Page 1 of 2  [1] 2  Next page →

#23969 — casting unsigned int to void*

The Xpm pixmap library contains code that casts an unsigned int
to a (void *), passing that as an argument to a function
that expects a (void *):

/* Function prototype: */
xpmHashIntern (xpmHashTable *table, char *tag, void *data));

/* Calling it, casting 3rd argument: */
int a = <something>;
xpmHashIntern(hashtable, color->string, (void *)a );

On a 64-bit platform where pointers are 64 bits and ints
are 32 bits, is this safe?

[toc] | [next] | [standalone]

#23972

On 7/30/2012 1:33 PM, Fred K wrote:
> The Xpm pixmap library contains code that casts an unsigned int
> to a (void *), passing that as an argument to a function
> that expects a (void *):
>
> /* Function prototype: */
> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
>
> /* Calling it, casting 3rd argument: */
> int a = <something>;
> xpmHashIntern(hashtable, color->string, (void *)a );
>
> On a 64-bit platform where pointers are 64 bits and ints
> are 32 bits, is this safe?

     For suitable definitions of "safe," yes.  Presumably the goal
is to be able to convert the `void*' back to an `unsigned(?) int'
and recover the original "<something>".  If so,

     - The C language does not guarantee that this will work (no,
       not even if you use `intptr_t' or `uintptr_t'), but

     - It will work on every 64-bit machine I've ever encountered,
       and I haven't heard of any where it wouldn't.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#23980

In article <jv6i1p$ch0$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 7/30/2012 1:33 PM, Fred K wrote:
>
>     For suitable definitions of "safe," yes.  Presumably the goal
>is to be able to convert the `void*' back to an `unsigned(?) int'
>and recover the original "<something>".  If so,
>
>     - The C language does not guarantee that this will work (no,
>       not even if you use `intptr_t' or `uintptr_t'), but
>
>     - It will work on every 64-bit machine I've ever encountered,
>       and I haven't heard of any where it wouldn't.

Agreed.  The spec may not support it, but it should be safe on
most machines, as long as the size of void* is >= the size of int.

It would fail on a 286 with the wrong compiler options, and maybe a
PDP-11, but would be safe on any other machine I've ever worked on.

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

[toc] | [prev] | [next] | [standalone]

#23973

On 07/30/2012 01:33 PM, Fred K wrote:
> The Xpm pixmap library contains code that casts an unsigned int
> to a (void *), passing that as an argument to a function
> that expects a (void *):
> 
> /* Function prototype: */
> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
> 
> /* Calling it, casting 3rd argument: */
> int a = <something>;
> xpmHashIntern(hashtable, color->string, (void *)a );
> 
> On a 64-bit platform where pointers are 64 bits and ints
> are 32 bits, is this safe?


The fact that pointers are 64 bits and ints are 32 bits makes it more
difficult for this to work, but not impossible. On a platform where both
are the same size, it's more likely to work, but that's still not
guaranteed. The precise requirements are as follows:

Converting an integer constant expression with a value of 0 to void* is
guaranteed by the standard to result in a null pointer value.

Converting a pointer to void into either intptr_t or uintptr_t produces
a value that can be converted back to void*, resulting in a pointer that
is equivalent to the original pointer. Those two types are optional; if
supported, they are defined in <stdint.h>, which was introduced in C99.
You can check whether they are supported by checking whether INTPTR_MAX
or UINTPTR_MAX are #defined.

In all other cases, while converting an integer value to a pointer is
permitted, "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."

Whether or not this code works correctly is therefore
implementation-specific. It would never have been written and released
unless it actually did work, somewhere, but that's no guarantee that it
will work anywhere else.

[toc] | [prev] | [next] | [standalone]

#23975

On Monday, July 30, 2012 11:14:34 AM UTC-7, James Kuyper wrote:
> On 07/30/2012 01:33 PM, Fred K wrote: > The Xpm pixmap library contains code that casts an unsigned int > to a (void *), passing that as an argument to a function > that expects a (void *): > > /* Function prototype: */ > xpmHashIntern (xpmHashTable *table, char *tag, void *data)); > > /* Calling it, casting 3rd argument: */ > int a = <something>; > xpmHashIntern(hashtable, color->string, (void *)a ); > > On a 64-bit platform where pointers are 64 bits and ints > are 32 bits, is this safe? The fact that pointers are 64 bits and ints are 32 bits makes it more difficult for this to work, but not impossible. On a platform where both are the same size, it's more likely to work, but that's still not guaranteed. The precise requirements are as follows: Converting an integer constant expression with a value of 0 to void* is guaranteed by the standard to result in a null pointer value. Converting a pointer to void into either intptr_t or uintptr_t produces a value that can be converted back to void*, resulting in a pointer that is equivalent to the original pointer. Those two types are optional; if supported, they are defined in <stdint.h>, which was introduced in C99. You can check whether they are supported by checking whether INTPTR_MAX or UINTPTR_MAX are #defined. In all other cases, while converting an integer value to a pointer is permitted, "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." Whether or not this code works correctly is therefore implementation-specific. It would never have been written and released unless it actually did work, somewhere, but that's no guarantee that it will work anywhere else.

Well, it was written a long time ago, and for platforms where the size of an int was the same size as a pointer. So far, I haven't found a problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to several flavors of (64-bit) Linux, and iPad. Time will tell...

[toc] | [prev] | [next] | [standalone]

#23978

There was some really unforgivable formatting in here, especially the more
deeply quoted parts, so I chopped them out. Google Groups sucks! Get a
real newsreader!

In article <afc78550-acc3-4f3f-b9e6-5dcbe1e33061@googlegroups.com>,
Fred K  <fred.l.kleinschmidt@gmail.com> wrote:
[about xpm]
>
>Well, it was written a long time ago, and for platforms where the size
>of an int was the same size as a pointer. So far, I haven't found a
>problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to
>several flavors of (64-bit) Linux, and iPad. Time will tell...

Xpm isn't some dead artifact you just dug up that nobody else remembers. It has
been continuously maintained and is still distributed by x.org.

Why can't you use their version? It should already be bundled with your
Linux distribution.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#23983

On Monday, July 30, 2012 11:46:51 AM UTC-7, Alan Curry wrote:
> There was some really unforgivable formatting in here, especially the more deeply quoted parts, so I chopped them out. Google Groups sucks! Get a real newsreader! In article <afc78550-acc3-4f3f-b9e6-5dcbe1e33061@googlegroups.com>, Fred K <fred.l.kleinschmidt@gmail.com> wrote: [about xpm] > >Well, it was written a long time ago, and for platforms where the size >of an int was the same size as a pointer. So far, I haven't found a >problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to >several flavors of (64-bit) Linux, and iPad. Time will tell... Xpm isn't some dead artifact you just dug up that nobody else remembers. It has been continuously maintained and is still distributed by x.org. Why can't you use their version? It should already be bundled with your Linux distribution. -- Alan Curry

I just downloaded the current version (including source code) and it still has that code in it, so they are currently using code that may be problematic.

[toc] | [prev] | [next] | [standalone]

#23990

Fred K <fred.l.kleinschmidt@gmail.com> writes:

> On Monday, July 30, 2012 11:46:51 AM UTC-7, Alan Curry wrote:
>> There was some really unforgivable formatting in here, especially the more deeply quoted parts, so I chopped them out. Google Groups sucks! Get a real newsreader! In article <afc78550-acc3-4f3f-b9e6-5dcbe1e33061@googlegroups.com>, Fred K <fred.l.kleinschmidt@gmail.com> wrote: [about xpm] > >Well, it was written a long time ago, and for platforms where the size >of an int was the same size as a pointer. So far, I haven't found a >problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to >several flavors of (64-bit) Linux, and iPad. Time will tell... Xpm isn't some dead artifact you just dug up that nobody else remembers. It has been continuously maintained and is still distributed by x.org. Why can't you use their version? It should already be bundled with your Linux distribution. -- Alan Curry

There is something odd with your quoting!  Is this another Google groups
issue?

> I just downloaded the current version (including source code) and it
> still has that code in it, so they are currently using code that may
> be problematic.

The "may" is key.  It may be problematic, but I doubt it.  It's a very
common trick, and every implementation I've used defines the conversion
in a way that makes recovery of the int (the actual purpose here) safe.

You are doing the porting, are you not?  Is it actually a problem?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23979

On 07/30/2012 07:33 PM, Fred K wrote:
> The Xpm pixmap library contains code that casts an unsigned int
> to a (void *), passing that as an argument to a function
> that expects a (void *):
> 
> /* Function prototype: */
> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
> 
> /* Calling it, casting 3rd argument: */
> int a = <something>;
> xpmHashIntern(hashtable, color->string, (void *)a );
> 
> On a 64-bit platform where pointers are 64 bits and ints
> are 32 bits, is this safe?

it is not safe - standard does not give you any guarantees on that. it
may work, on some machines. if the intend was to pass an int value via
void* it should be int's address, not the value (i.e. void foo(void*);
foo(&a)). you should probably contact the maintainer of this code.

-- 
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.eu */

[toc] | [prev] | [next] | [standalone]

#23992

In article <7edfdd82-a84a-4391-8a63-4a537668d4b7@googlegroups.com>,
 Fred K <fred.l.kleinschmidt@gmail.com> wrote:

> The Xpm pixmap library contains code that casts an unsigned int
> to a (void *), passing that as an argument to a function
> that expects a (void *):
> 
> /* Function prototype: */
> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
> 
> /* Calling it, casting 3rd argument: */
> int a = <something>;
> xpmHashIntern(hashtable, color->string, (void *)a );
> 
> On a 64-bit platform where pointers are 64 bits and ints
> are 32 bits, is this safe?

intptr_t is an integer which is large enough to hold a void* pointer encoded in 
an integer. This is an ancient bug dating back to the days when an integer was 
60 bits, would always be 60 bits, and an address was 18 bits, and would always 
be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits), 
exposing this bad assumption.  The intptr_t was eventually introduced to provide 
an integer that would always be safe to hold addresses.

-- 
My name Indigo Montoya.      |            Die, Robbie Ferrier! Die!
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#23996

On 07/30/2012 04:04 PM, China Blue [Tor], Meersburg wrote:
...
> intptr_t is an integer which is large enough to hold a void* pointer encoded in 
> an integer. This is an ancient bug dating back to the days when an integer was 
> 60 bits, would always be 60 bits, and an address was 18 bits, and would always 

Your descriptions seem highly platform-specific; I'm not familiar with a
platform that had those particular characteristics. Could you identify it?

> be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits), 
> exposing this bad assumption.  The intptr_t was eventually introduced to provide 
> an integer that would always be safe to hold addresses.

[toc] | [prev] | [next] | [standalone]

#24000

In article <5016ECE9.3050605@verizon.net>,
 James Kuyper <jameskuyper@verizon.net> wrote:

> On 07/30/2012 04:04 PM, China Blue [Tor], Meersburg wrote:
> ...
> > intptr_t is an integer which is large enough to hold a void* pointer 
> > encoded in 
> > an integer. This is an ancient bug dating back to the days when an integer 
> > was 
> > 60 bits, would always be 60 bits, and an address was 18 bits, and would 
> > always 
> 
> Your descriptions seem highly platform-specific; I'm not familiar with a
> platform that had those particular characteristics. Could you identify it?

http://en.wikipedia.org/wiki/CDC_6600

-- 
My name Indigo Montoya.      |            Die, Robbie Ferrier! Die!
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#24002

On 07/30/2012 05:55 PM, China Blue [Tor], Meersburg wrote:
> In article <5016ECE9.3050605@verizon.net>,
>  James Kuyper <jameskuyper@verizon.net> wrote:
> 
>> On 07/30/2012 04:04 PM, China Blue [Tor], Meersburg wrote:
>> ...
>>> intptr_t is an integer which is large enough to hold a void* pointer 
>>> encoded in 
>>> an integer. This is an ancient bug dating back to the days when an integer 
>>> was 
>>> 60 bits, would always be 60 bits, and an address was 18 bits, and would 
>>> always 
>>
>> Your descriptions seem highly platform-specific; I'm not familiar with a
>> platform that had those particular characteristics. Could you identify it?
> 
> http://en.wikipedia.org/wiki/CDC_6600

Can you give us any particular reason to believe that this particular
processor had a major role to play in setting up expectations, relevant
to the design of C, that were later violated by the Intel 8086 family of
processors, as implied by your earlier message? Your wording gave the
impression that 60-bit integers were so widely used that many people
thought they were universal. The article you linked to refers to the
60-bit words as "very large", belying that implication.

[toc] | [prev] | [next] | [standalone]

#24003

In article <5017077F.7050601@verizon.net>,
 James Kuyper <jameskuyper@verizon.net> wrote:

> On 07/30/2012 05:55 PM, China Blue [Tor], Meersburg wrote:
> > In article <5016ECE9.3050605@verizon.net>,
> >  James Kuyper <jameskuyper@verizon.net> wrote:
> > 
> >> On 07/30/2012 04:04 PM, China Blue [Tor], Meersburg wrote:
> >> ...
> >>> intptr_t is an integer which is large enough to hold a void* pointer 
> >>> encoded in 
> >>> an integer. This is an ancient bug dating back to the days when an 
> >>> integer 
> >>> was 
> >>> 60 bits, would always be 60 bits, and an address was 18 bits, and would 
> >>> always 
> >>
> >> Your descriptions seem highly platform-specific; I'm not familiar with a
> >> platform that had those particular characteristics. Could you identify it?
> > 
> > http://en.wikipedia.org/wiki/CDC_6600
> 
> Can you give us any particular reason to believe that this particular
> processor had a major role to play in setting up expectations, relevant
> to the design of C, that were later violated by the Intel 8086 family of
> processors, as implied by your earlier message? Your wording gave the
> impression that 60-bit integers were so widely used that many people
> thought they were universal. The article you linked to refers to the
> 60-bit words as "very large", belying that implication.

It was a joke illustrating a common mistake about assuming sizeofs.

-- 
My name Indigo Montoya.      |            Die, Robbie Ferrier! Die!
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#24016

On 30/07/2012 23:18, China Blue [Tor], Meersburg wrote:

> It was a joke illustrating a common mistake about assuming sizeofs.

Clearly an example of alternative comedy. Comedy is usually funny, this 
is the alternative.

[toc] | [prev] | [next] | [standalone]

#24018

In article <jv81ji$77g$1@dont-email.me>, Mark Bluemel <mark_bluemel@pobox.com> 
wrote:

> On 30/07/2012 23:18, China Blue [Tor], Meersburg wrote:
> 
> > It was a joke illustrating a common mistake about assuming sizeofs.
> 
> Clearly an example of alternative comedy. Comedy is usually funny, this 
> is the alternative.

'Assholes do vex me.'

-- 
My name Indigo Montoya.      |            Die, Robbie Ferrier! Die!
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#24005

"China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> writes:

> In article <7edfdd82-a84a-4391-8a63-4a537668d4b7@googlegroups.com>,
>  Fred K <fred.l.kleinschmidt@gmail.com> wrote:
>
>> The Xpm pixmap library contains code that casts an unsigned int
>> to a (void *), passing that as an argument to a function
>> that expects a (void *):
>> 
>> /* Function prototype: */
>> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
>> 
>> /* Calling it, casting 3rd argument: */
>> int a = <something>;
>> xpmHashIntern(hashtable, color->string, (void *)a );
>> 
>> On a 64-bit platform where pointers are 64 bits and ints
>> are 32 bits, is this safe?
>
> intptr_t is an integer which is large enough to hold a void* pointer
> encoded in an integer. This is an ancient bug dating back to the days
> when an integer was 60 bits, would always be 60 bits, and an address
> was 18 bits, and would always be 18 bits. The 80x86s had addresses (20
> bits) larger than ints (16 bits), exposing this bad assumption.

It's never been an assumption made by C -- even pre-ANSI C.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24010

On 7/30/2012 4:04 PM, China Blue [Tor], Meersburg wrote:
> In article <7edfdd82-a84a-4391-8a63-4a537668d4b7@googlegroups.com>,
>   Fred K <fred.l.kleinschmidt@gmail.com> wrote:
>
>> The Xpm pixmap library contains code that casts an unsigned int
>> to a (void *), passing that as an argument to a function
>> that expects a (void *):
>>
>> /* Function prototype: */
>> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
>>
>> /* Calling it, casting 3rd argument: */
>> int a = <something>;
>> xpmHashIntern(hashtable, color->string, (void *)a );
>>
>> On a 64-bit platform where pointers are 64 bits and ints
>> are 32 bits, is this safe?
>
> intptr_t is an integer which is large enough to hold a void* pointer encoded in
> an integer.

     intptr_t and uintptr_t are both irrelevant to the O.P.'s
question.  The fact that a void* can be converted to a [u]intptr_t
which can be in turn converted to a void* with the two pointers
comparing equal does not imply that a [u]intptr_t can be converted
to a void* and then back to a [u]intptr_t with the two integers
equal.

	P1 -> I -> P2, P2 == P1
	I1 -> P -> I2, I2 ?= I1 (no guarantee)

> This is an ancient bug

     Makes no sense.  It can't be any more ancient than C99, which
introduced the types.  "Bug" can be a subjective judgement, but it's
certainly debatable whether the existence of [u]intptr_t is a "bug."
People who want to convert pointers to integers and back probably
dispute your assessment.

> dating back to the days when an integer was
> 60 bits, would always be 60 bits, and an address was 18 bits, and would always
> be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits),
> exposing this bad assumption.

     Is this supposed to be an argument that [u]intptr_t is a "bug?"
I cannot comprehend what it's supposed to be about.

> The intptr_t was eventually introduced to provide
> an integer that would always be safe to hold addresses.

     Not quite.  The [u]intptr_t types are optional, meaning
that they are not "always" safe to hold addresses.  Also, there
has been no introduction of addresses that are safe to hold
integers.  Finally, none of this is "ancient" except to pre-teens.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24022

On 07/30/2012 08:45 PM, Eric Sosman wrote:
> On 7/30/2012 4:04 PM, China Blue [Tor], Meersburg wrote:
>> In article <7edfdd82-a84a-4391-8a63-4a537668d4b7@googlegroups.com>,
>>   Fred K <fred.l.kleinschmidt@gmail.com> wrote:
>>
>>> The Xpm pixmap library contains code that casts an unsigned int
>>> to a (void *), passing that as an argument to a function
>>> that expects a (void *):
>>>
>>> /* Function prototype: */
>>> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
>>>
>>> /* Calling it, casting 3rd argument: */
>>> int a = <something>;
>>> xpmHashIntern(hashtable, color->string, (void *)a );
>>>
>>> On a 64-bit platform where pointers are 64 bits and ints
>>> are 32 bits, is this safe?
>>
>> intptr_t is an integer which is large enough to hold a void* pointer encoded in
>> an integer.
> 
>      intptr_t and uintptr_t are both irrelevant to the O.P.'s
> question. ...

No, they are not.

> ... The fact that a void* can be converted to a [u]intptr_t
> which can be in turn converted to a void* with the two pointers
> comparing equal does not imply that a [u]intptr_t can be converted
> to a void* and then back to a [u]intptr_t with the two integers
> equal.
> 
> 	P1 -> I -> P2, P2 == P1
> 	I1 -> P -> I2, I2 ?= I1 (no guarantee)

Agreed. However, we were not told how the integer value was chosen, nor
what xpmHashIntern() did with it. If you're familiar with xpm, it might
seem obvious. However, for those of us who are not, the possibilities
are quite open-ended. One way that code similar to the code above could
have worked is as follows:

	double d = 3.14;
	intptr_t a = (intptr_t)(void*)&d;

	xpmHashIntern(hashtable, color->string, (void*)a);

	xpmHashIntern (xpmHashTable *table, char *tag, void *data))
	{
 	    /* ... stuff ... */
	    double *pd = data;
	    /* ... more stuff, making use of *pd ... */
	}

Using int rather than intptr_t could therefore work on a particular
implementation, if the result of (intptr_t)(void*)d happened to be
representable as an int on that implementation. That's not something
that code intended to be portable should rely upon, but it does provide
one possible way that such non-portable code like that might have worked
on a particular implementation.

>> This is an ancient bug
> 
>      Makes no sense.  It can't be any more ancient than C99, which
> introduced the types.  "Bug" can be a subjective judgement, but it's
> certainly debatable whether the existence of [u]intptr_t is a "bug."

I didn't see anything that suggested that the existence of [u[intptr_t
was a bug. The "bug" he's referring to is the use of 'int' rather than
'intprt_t' in the original code.

...
>> dating back to the days when an integer was
>> 60 bits, would always be 60 bits, and an address was 18 bits, and would always
>> be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits),
>> exposing this bad assumption.
> 
>      Is this supposed to be an argument that [u]intptr_t is a "bug?"

No.

> I cannot comprehend what it's supposed to be about.

It's meant to be an explanation of the problem that [u]intptr_t was
invented to solve. It fails primarily due to the fact that numbers given
were apparently chosen for humorous effect, rather than plausibility. It
would have been a lot more plausible if 60 and 18 had both been changed
to 16.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#24006

Fred K <fred.l.kleinschmidt@gmail.com> writes:
> The Xpm pixmap library contains code that casts an unsigned int
> to a (void *), passing that as an argument to a function
> that expects a (void *):
>
> /* Function prototype: */
> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
>
> /* Calling it, casting 3rd argument: */
> int a = <something>;
> xpmHashIntern(hashtable, color->string, (void *)a );
>
> On a 64-bit platform where pointers are 64 bits and ints
> are 32 bits, is this safe?

Others have addressed the safety (or lack thereof) of doing this.

The "void *data" parameter is intended for passing arbitrary information
into the function.  A safer way to pass an int value is to pass the
address of an int object:

    int a = <something>;
    int *p = malloc(sizeof *p);
    /* check for allocation error */
    xpmHashIntern(hashtable, color->string, p);

I used malloc to ensure that the object continues to exist as long as
it's needed; if it's a one-off object, declaring "a" as static would
also work.

This assumes, of course, that the code that retrieves the value from the
hash table knows to treat it as a pointer to an int object.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web