[Python-Dev] test_builtin failing? or just 64-bit platforms (original) (raw)

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 PyOSsnprintf 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