RetroSearch Browse

Wed May 31 03:24:05 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-May/065452.html

[Bob Ippolito]
> It seems that we should convert the crc32 functions in binascii,
> zlib, etc. to deal with unsigned integers. Currently it seems that 32-
> bit and 64-bit platforms are going to have different results for
> these functions.

binascii.crc32 very deliberately intends to return the same signed
integer values on all platforms.  That's what this section at the end
is trying to do:

#if SIZEOF_LONG > 4
	/* Extend the sign bit.  This is one way to ensure the result is the
	 * same across platforms.  The other way would be to return an
	 * unbounded unsigned long, but the evidence suggests that lots of
	 * code outside this treats the result as if it were a signed 4-byte
	 * integer.
	 */
	result |= -(result & (1L << 31));
#endif
	return PyInt_FromLong(result);

I wouldn't try to fight that, unless that code is buggy (it looks
correct to me).  I don't remember "the evidence" now, but Barry & I
found "lots of code" relying on it at the time ;-)

> Should we do the same as the struct module, and do DeprecationWarning
> when the input value is < 0?

If the _result_ is going to change from sometimes-negative to
always-positive, then FutureWarning is most appropriate.

> ...
> None of the unit tests seem to exercise values where 32-bit and 64-
> bit platforms would have differing results, but that's easy enough to
> fix...

As above, it shouldn't be possible to concoct a case where
binascii.crc32's result differ across boxes.  That function also
intends to treat negative inputs the same way across boxes.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-May/065452.html below:

[Python-Dev] Converting crc32 functions to use unsigned