[Python-3000] zlib.crc32 - signed or unsigned?

[Gregory P. Smith]

On 3/19/08, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>
> Christian Heimes schrieb:
>
> > In Python 3.0 the unit test for zlib is broken because in 3.0
> > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed
> int.
> >
> > How should the issue be solved? I think the unsigned long is wrong.
>
>
> Here at the sprint people agreed that crc32 *obviously* gives
> an unsigned number.
>
> It's unfortunate that Python 2.6 can't really implement that
> very well, hence we have to keep the 2.x behavior in 2.6.
> In 3k, it should change.
>
> Regards,
>
> Martin


yes crcs should be unsigned; they're fixed size bit fields.  it could even
make sense to return them as a 4 byte bytes/str object but that'd be an API
change.  a sign requires you to assume you know the length of the underlying
integer holding it.  python ints and longs don't have a fixed size so that
is troublesome and leads to lots of zlib.crc32(foo) & 0xffffffff and
binascii.crc32(foo) & 0xffffffff or other ugly tricks to un-sign the value.

I could make 2.6 return unsigned but it would mean that it returns a long
half of the time rather than an int.  The informal consensus in the room
earlier this week was to leave 2.x returning a signed value for
compatibility (I made it consistent so that it -always- returns a signed
regardless of sizeof(long)).  i'd be happy either way.

My recent checkin should have fixed the py3k tests and got them returning
unsigned again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080320/4bc66f4d/attachment.htm