[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