[Patches] Fix for bug PR#341

[Tim Peters]

[MAL's Fix to avoid buffer overruns in %-formatting of integers]

[Fred]
> I've not read the files you're patching for this one, but is
> this really the right patch?  How did you come up with 50?

[MAL]
> Simple: the code for the float formatting uses the same
> limit and I find it reasonably high to not cause any
> harm to existing programs.

[Fred]
> I'm also not comfortable with the magic numbers in the source.

[MAL]
> Well, the limits seem arbitrary, but then: who will want
> to print integers with more than 40 digits (2^128 + sign) ?

I can't object to the patch, but I'll join Fred in objecting to the code
it's mimicking:  not only do magic numbers suck, but these particular magic
numbers implicitly rely on PyString_Format's tmpbuf vector being declared of
another magical size larger than them.  As usual, flaky code gets flakier.

This doesn't need to be "fixed" now, though.  Note that as Python erases the
distinction between its ints and longs, there will be *no* a priori bound we
can put on a "reasonable" buffer size here (the only thing saving us now is
Python's surprising refusal to do integer formatting of longs; e.g.,

>>> "The answer is %d." % 100000000000000L
Traceback (innermost last):
  File "<pyshell#5>", line 1, in ?
    "%d" % 100000000000000L
OverflowError: long int too long to convert
>>>

).

one-step-forward-one-step-back-ly y'rs  - tim