Old bug in longobject.c + fix

[Tim Peters]

[Paul Sheer]
> ...
> OF COURSE this bug is not perceptable in current
> builds - thousands of apps use left shifting. But
> one day twodigits will be u_int64_t

It won't.  uint64_t isn't a required type in C99, so Python will probably
never use it.  It may use uint_fast64_t someday, though.

> - so I've just saved some future programmer many hours of debugging.

I don't know why you believe that.  twodigits is already wider than digit on
almost all current platforms, and it simply doesn't matter in real life.  I
did the first port of Python to a 64-bit box (back in '93), and indeed
twodigits was a 64-bit type there, while digit was a 16-bit type, and it
didn't matter there either.  There's no potential trouble here in real life
*unless* you boost BASE and SHIFT too.

> BTW, when this FINALLY gets patched (Python 8.0 I expect),

Since it has no visible consequence on any known or anticipated platform,
there's no priority for changing it.  If you think it's important enough to
do the work, please submit a patch on SourceForge to do so, and note that
there are several instances of this kind of shift in longobject.c.

> then we can move twdigits over to long long, and get the 80% speed
> increase I have already demonstrated here in my kitchen.

I assume you meant to say that you also boosted the values of BASE and
SHIFT, and made digit wider too.  If you got a speed boost from *just*
boosing the width of twodigits, that would be a miracle, and you should
double-check your results <wink>.

Note that boosting the size of digit has other consequences, including
maintaining the guarantee that marshal data remain portable across releases,
and in estimating the amount of space needed for unbounded-int base
conversions.  If digit ever does get boosted, it will require a lot more
work than just changing some macro values and fixing some shifts.