Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too.

On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations).

The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct.

We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString).