]> granicus.if.org Git - python/commit
Fix for SF bug 110624: float literals behave inconsistently.
authorTim Peters <tim.peters@gmail.com>
Sat, 23 Sep 2000 03:39:17 +0000 (03:39 +0000)
committerTim Peters <tim.peters@gmail.com>
Sat, 23 Sep 2000 03:39:17 +0000 (03:39 +0000)
commitef14d73b7af06d94c7ddf4adf27d1ddeb84d651e
treef456e340d1b0ff1909d73c98d7a5bd07e2660cb3
parent891150bdf2773b9e8ad9e92db073805afd7722cd
Fix for SF bug 110624:  float literals behave inconsistently.
I fixed the specific complaint but left the (many) large issues untouched.
See the (very long) bug report discussion for why:
    http://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=110624
Note that while I left the interface to the undocumented public API function
PyFloat_FromString alone, its 2nd argument is useless.  From a comment block
in the code:

RED_FLAG 22-Sep-2000 tim
PyFloat_FromString's pend argument is braindead.  Prior to this RED_FLAG,

1.  If v was a regular string, *pend was set to point to its terminating
    null byte.  That's useless (the caller can find that without any
    help from this function!).

2.  If v was a Unicode string, or an object convertible to a character
    buffer, *pend was set to point into stack trash (the auto temp
    vector holding the character buffer).  That was downright dangerous.

Since we can't change the interface of a public API function, pend is
still supported but now *officially* useless:  if pend is not NULL,
*pend is set to NULL.
Objects/floatobject.c