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

Groups > comp.lang.c > #24022

Re: casting unsigned int to void*

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web