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 -- http://mail.python.org/mailman/listinfo/python-list
