[Python-Dev] test_builtin failing? or just 64-bit platforms
Sun, 2 Dec 2001 03:41:28 -0500
> 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
if-it-cost-6-billion-it-must-be-worth-at-least-12-ly y'rs - tim