[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"

SourceForge.net noreply at sourceforge.net
Tue Mar 6 12:10:52 CET 2007


Bugs item #1673757, was opened at 2007-03-04 21:34
Message generated for change (Comment added) made by ericvsmith
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 3000
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: 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


More information about the Python-bugs-list mailing list