Old bug in longobject.c + fix

[Duncan Booth]

Pearu Peterson <pearu at cens.ioc.ee> wrote in
news:mailman.1029739528.11324.python-list at python.org: 

> On 18 Aug 2002, Antti Louko wrote:
> 
>> Gerhard Häring <gerhard.haering at gmx.de> writes:
>> 
>> > * Paul Sheer <psheer at icon.co.za> [2002-08-18 22:05 +0200]:
>> > > I think that its pretty damn obvious the "nature" of the bug
>> > 
>> > No. How long would it take you to describe what your patch is
>> > about? Two
>> > minutes? How long would it take a Python developer to find out what
>> > your
>> > patch tries to change and why? 10 minutes? 30 minutes?
>> 
>> Actually, it takes about ten seconds to guess what the bug is and one
>> minute to be sure after you have checked a few things.
> 
> I am curious. What is this bug about? Can you just tell it so that one
> does not need to rebuild the python to see the effect (if any?).
> 
I'm not entirely sure that I've got this right, but my reading of the code 
is this:

a->ob_digit[j] is an unsigned short. When you try to left shift it, it is 
autmoatically promoted to unsigned int. accum is of type unsigned long and 
the cast that the OP wants to add will force the original value to be 
promoted to unsigned long and shifted as one.

On many systems you can expect the C types unsigned short to be 16 bits, 
unsigned int 32 bits and unsigned long 32 bits. When this is the case, the 
cast has no detectable effect. Therefore on most systems the bug is 
completely undetectable.

However, it is possible that unsigned int is 16 bits, in which case the 
left shift will lose significant bits that should be preserved. The cast is 
required to prevent this happening.

I think one minute is a bit optimistic as the time to work this out unless 
you already know longobject representations backwards. 10 minutes OTOH is 
pessimistic. I suspect though that the developers have better things to do 
with their time than try to deduce the reasoning behind the patch.

Would anyone care to list some systems which run Python and where the C 
'int' type is represented on only 16 bits?

-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?