Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:58 Message: Logged In: YES user_id=6380 Originator: NO Changing the group to 2.5; see the patch (http://python.org/sf/1673759) for an explanation. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES The patch was corrected, and tests added. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO 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). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
