[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4