unsigned 32 bit arithmetic type?

"Martin v. Löwis" martin at v.loewis.de
Wed Oct 25 13:20:51 EDT 2006


Robin Becker schrieb:
> Of course the actual semantics is dependent on what C unsigned
> arithmetic does so we're relying on that being the same everywhere.

Assuming that ULONG has the same width on all systems, the outcome
is actually mandated by the C standard: unsigned arithmetic is
defined to operate modulo (max_uint+1) (even if that is not a power
of two).

> This algorithm was pretty simple in Python until 2.3 when shifts over
> the end of ints started going wrong.

Actually, they start going *right* :-) Addition of two positive numbers
never gives a negative result, in mathematics.

> where while it might be reasonable to do testing it seems the tests
> aren't very sensible eg what is -6 doing in a u32 test? This stuff just
> about works on a 32 bit machine, but is failing miserably on a 64bit
> AMD. As far as I can see I just need to use masked longs throughout.

Exactly.

> In a C extension I can still do the computation exfficiently on a 32bit
> machine, but I need to do masking for a 64 bit machine.

Well, no. You just need to find a 32-bit unsigned integer type on the
64-bit machine. Typically, "unsigned int" should work fine (with
only the Cray being a notable exception, AFAIK). IOW, replace ULONG
with uint32_t wherever you really mean an unsigned 32-bit type,
then use stdint.h where available, else define it to unsigned int
(with a build-time or run-time test whether sizeof(unsigned int)==4).

Regards,
Martin



More information about the Python-list mailing list