This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: string and unicode formatting are missing a test for "G"
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, georg.brandl, gvanrossum, ncoghlan
Priority: normal Keywords:

Created on 2007-03-05 02:34 by eric.smith, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg31423 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2007-03-05 02:34
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.
msg31424 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2007-03-05 02:42
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'.
msg31425 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2007-03-05 02:47
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.
msg31426 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2007-03-06 10:55
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).




msg31427 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2007-03-06 10:57
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.
msg31428 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2007-03-06 11:10
The patch was corrected, and tests added.
msg31429 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-03-18 03:58
Changing the group to 2.5; see the patch (http://python.org/sf/1673759) for an explanation.
msg31430 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-07-12 08:38
Patch was committed.
History
Date User Action Args
2022-04-11 14:56:22adminsetgithub: 44658
2007-03-05 02:34:13eric.smithcreate