[Bf-python] 64-bit and void*/int hackery

[Martin Poirier]

--- Ken Hughes <khughes at pacific.edu> wrote:

> Throwing this out for general comments:
> 
> Back when I started adding tp_getset goodness to the
> API, there were 
> many places where I wrapped a common handler
> function (for example, for 
> bitmasks) by using a void* to hold a constant:
> 
>     {"useAlpha",
>      (getter)Texture_getImageFlags,
> (setter)Texture_setImageFlags,
>      "Use of image's alpha channel enabled
> ('ImageFlags')",
>      (void *)TEX_USEALPHA},
> 
> and then cast to an integer inside the function to
> get the value.  Of 
> course, gcc complains about this on 64-bit
> platforms:
> 
>     warning: cast from pointer to integer of
> different size
> 
> In some places I later coded around this by first
> casting to a long, 
> then masking the result:
>  
>  switch ( (int)((long)type & UINT_MAX) ):
> 
> This seems really hackish to me, plus I don't know
> if it fixes warnings  on other platforms.

It won't fix it on win64, long aren't 64bits wide on
that platform.

It would be better to use a defined pointer-length
type for that purpose (defined per platform).

> An alternative would be to
> actually pass pointers 
> to real data; the overhead in terms of wasted memory
> is probably minimal.
> 
> Is this a problem we should try to fix in the code,
> or is it just me 
> that's bothered by this?

As long as we're sure the range of values fits in a
int, I'm ok with the case.

The magic to remove the warning could/should be hidden
in a macro. It's not the only place we might cast
pointer, so it could be reusable.

Martin


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ