Re: [pygame] chewy changes to cvs

["ShredWheat" <shredwheat@mediaone.net>]

> Something I noticed in the code could be causing some wierdness, but I 
> haven't really tested it yet:
> in surface.c surf_map_rgb declares "color" as an int but uses 
> PyInt_FromLong(color) to return the value to Python.  I'm not familiar 
> enough with the Python interface to be sure, but it looks like this 
> could pick up some garbage from outside the int memory space.

hi dave, the good news is, no need to worry. 
this code is fine, but there's a couple quick points i can
make to put your mind at rest :] 

the first is inconsequential, but on most 32bit platforms
"int" is same as "long". both store a 32bit signed integer.
what makes portable C code somewhat tricky is that a "short"
is only guaranteed to be sized equal or lesser than an int,
while "long" is guaranteed to be sized equal or greater than int.

what makes PyInt_FromLong() work fine with any integer value
is that C will automatically convert types to another. i could
pass a float value to PyInt_FromLong and know C will convert it
to a long for me. most books will explain this under "Standard
Conversions" or something like that.

now if PyInt_FromLong took a pointer to a long, then we'd be
in a world of difference. first, any compiler will complain that
you passed a pointer to int instead of a pointer to long. the
compiler should make you "cast" the pointer to the needed type.
once that is done, then your guess that PyInt_FromLong was getting
extra random bits woule be correct.

anyways, hopefully this is just a quick enough intro to C to
give you a basic idea of what's going on. just because you asked
though, i did doublecheck the prototype for PyInt_FromLong

PyObject* PyInt_FromLong(long);


it makes me smile inside to know people are looking at the code
though, :]



____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org