[Python-Dev] test_builtin failing? or just 64-bit platforms

Tim Peters tim.one@home.com
Sun, 2 Dec 2001 03:41:28 -0500


[Guido]
> ...
> Note that the Tru64 output suggests that the behavior (== effect on
> the buffer) may differ too: a truncated version of the desired output
> may or may not be written to the buffer.

Which later turned out to be our fault.  However, the MS native _snprintf is
worse than that:  if the buffer isn't big enough, it fills it to the end
*without* a trailing \0.  A subsequent (e.g.) PyString_FromString() would
then pick up an arbitrarily long stretch of garbage bytes beyond the
buffer's end.  You can see the effect by, e.g., making int_repr's buffer 4
bytes, then doing repr(sys.maxint), on Windows.

> This can be addressed by pre-filling the buffer with a useful pattern in
> PyOS_snprintf before calling the system's snprintf -- e.g. "*-*-*-*" (to
> give a patriotic example :-).

I don't know why you'd want to burn time doing this -- IMO, if the buffer
isn't big enough, it should almost always be due to an internal Python bug.
The point of PyOS_snprintf isn't to let us be lazy about buffer decls or
careless with formats, it's to prevent exploits even when we screw up.

> PS: I feel like I'm writing this on borrowed time -- Comcast and
> Excite@Home haven't disconnected me from the net yet. :-)

It's quite the soap opera!  AT&T pulled out of the talks, and AT&T's @Home
customers were then cut off.  The other partners are still negotiating.
Moral of the story:  if you ever start a moderately successful ISP, think
twice before spending 6 billion dollars to acquire a portal.  If you can't
resist, at least avoid selling your services below cost to companies much
bigger than you, counting on portal advertising dollars to make up the
difference.

if-it-cost-6-billion-it-must-be-worth-at-least-12-ly y'rs  - tim