[Bf-python] 64-bit and void*/int hackery
Campbell Barton
ideasman42 at gmail.com
Tue Feb 5 13:21:11 CET 2008
Would be nice to resolve this since it prints loads of annoying warnings
from this page...
http://www-128.ibm.com/developerworks/linux/library/l-port64.html
# size_t:
An unsigned integer and the result of the sizeof operator. This is
used when passing parameters to functions such as malloc (3), and
returned from several functions such as fred (2).
# intptr_t and uintptr_t:
seems like intptr_t could be used here, cant we just use defines for
compilers that dont have these built in?
On 2/5/08, Martin Poirier <theeth at yahoo.com> wrote:
>
> --- 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
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>
More information about the Bf-python
mailing list