php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49244 [PATCH] Floating point NaN cause garbage characters
Submitted: 2009-08-13 14:14 UTC Modified: 2009-11-02 18:07 UTC
From: ronlentjes at yahoo dot com dot au Assigned: felipe (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5.*, 6 (2009-09-20) OS: Linux Fedora 8
Private report: No CVE-ID: None
 [2009-08-13 14:14 UTC] ronlentjes at yahoo dot com dot au
Description:
------------
This has been an issue since 4.2.2 and still in 5.3.0.

$d = pow (-1.0, 0.3);  // or anything causing NaN
echo "$d\n";
 -> NAN
printf ("%f\n", $d);
(4.2.2) -> crash
(5.2.4) -> NaN<big-box><little-box><E-with-backslash-on-top>
(5.3.0) -> NaN<hex EF BF BD><hex EF BF BD><hex EF BF BD>
             (viewed in browser as NaN???)

Two issues here:
Inconsistent display of NAN for echo and NaN for printf.
Output of bogus characters after the 3 letters NaN for printf.

I think you are missing a '\0' null termination after the NaN characters which probably cause a runaway to crash 4.2.2 but is just 'hanging' in there for the newer versions.

Cheers,
Ron Lentjes
LC CLS.


Reproduce code:
---------------
$d = pow (-1.0, 0.3);
echo "$d\n";
printf ("%f\n", $d);


Expected result:
----------------
NaN
NaN

Actual result:
--------------
(4.2.2)
NAN
crash

(5.2.4)
NAN
NaN<big-box><little-box><E-with-backslash-on-top>

(5.3.0)
NAN
NaN<hex EF BF BD><hex EF BF BD><hex EF BF BD>
      (viewed in browser as NaN???)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-13 14:29 UTC] rasmus@php.net
I am unable to reproduce this in neither 5.2 nor 5.3, and Valgrind is clean on Debian.
 [2009-08-14 04:25 UTC] ronlentjes at yahoo dot com dot au
Perhaps you test it differently than I do. I'll give you the easiest way to see it happen:

put this in a file called test.php:
---
<?
$d = pow(-1.0, 0.3);
printf ("%f\n", $d);
?>
---

Output will be (bash, Fedora 8, Linux):

# php test.php
---
NaN*A
---

Output for browser will be NaN??? or NaN???F or other variations of that.

This is reporducable on versions 4.2.2 (crash), 5.2.4, 5.3.0 (as indicated previously).

I just retried this now.

Cheers,
Ron Lentjes
LC CLS.
 [2009-08-20 11:15 UTC] sjoerd-php at linuxonly dot nl
Could reproduce with PHP 5.2.10.
 [2009-08-20 19:19 UTC] sjoerd-php at linuxonly dot nl
The problem is with calling php_sprintf_appendstring. Its 9th parameter is not precision, it is length.

Index: ext/standard/formatted_print.c
===================================================================
--- ext/standard/formatted_print.c	(revision 287513)
+++ ext/standard/formatted_print.c	(working copy)
@@ -232,14 +232,14 @@
 	if (zend_isnan(number)) {
 		is_negative = (number<0);
 		php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0, padding,
-								 alignment, precision, is_negative, 0, always_sign);
+								 alignment, 3, is_negative, 0, always_sign);
 		return;
 	}
 
 	if (zend_isinf(number)) {
 		is_negative = (number<0);
 		php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0, padding,
-								 alignment, precision, is_negative, 0, always_sign);
+								 alignment, 3, is_negative, 0, always_sign);
 		return;
 	}
 [2009-09-01 16:34 UTC] garretts@php.net
sjoerd -- That fix works fine for me.

Can you commit that?

 [2009-09-20 10:24 UTC] sjoerd@php.net
I can't commit things. Somebody with SVN access should apply my patch and commit it. I've improved some things and added a testcase:

Index: ext/standard/formatted_print.c
===================================================================
--- ext/standard/formatted_print.c	(revision 288201)
+++ ext/standard/formatted_print.c	(working copy)
@@ -42,6 +42,8 @@
 #define FLOAT_PRECISION 6
 #define MAX_FLOAT_DIGITS 38
 #define MAX_FLOAT_PRECISION 40
+#define NOT_A_NUMBER "NaN"
+#define INFINITE "INF"
 
 #if 0
 /* trick to control varargs functions through cpp */
@@ -231,15 +233,15 @@
 	
 	if (zend_isnan(number)) {
 		is_negative = (number<0);
-		php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0, padding,
-								 alignment, precision, is_negative, 0, always_sign);
+		php_sprintf_appendstring(buffer, pos, size, NOT_A_NUMBER, strlen(NOT_A_NUMBER), 0, padding,
+					alignment, strlen(NOT_A_NUMBER), is_negative, 0, always_sign);
 		return;
 	}
 
 	if (zend_isinf(number)) {
 		is_negative = (number<0);
-		php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0, padding,
-								 alignment, precision, is_negative, 0, always_sign);
+		php_sprintf_appendstring(buffer, pos, size, INFINITE, strlen(INFINITE), 0, padding,
+					alignment, strlen(INFINITE), is_negative, 0, always_sign);
 		return;
 	}
 
Index: ext/standard/tests/strings/bug49244.phpt
===================================================================
--- ext/standard/tests/strings/bug49244.phpt	(revision 0)
+++ ext/standard/tests/strings/bug49244.phpt	(revision 0)
@@ -0,0 +1,8 @@
+--TEST--
+Bug #49244 (Floating point NaN cause garbage characters)
+--FILE--
+<?php
+printf("%f\n", pow(-1.0, 0.3));
+?>
+--EXPECT--
+NaN

 [2009-09-21 13:25 UTC] pajoye@php.net
Can you verify why your patch does not work in trunk please? There is still garbage. If you have a new patch, please post a link to it, the form breaks the patch format.
 [2009-10-01 11:38 UTC] sjoerd@php.net
With the patch applied, I could not reproduce the problem anymore. Pajoye still has problems, so it is not clear whether the patch solves this bug.

The patch can be found here:
http://www.gissen.nl/files/bug49244.patch
 [2009-11-02 17:37 UTC] svn@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=290150
Log: - Fixed bug #49244 (Floating point NaN cause garbage characters). (patch by Sjoerd)
 [2009-11-02 17:41 UTC] felipe@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Thanks for the patch. I've added more a change on the HEAD version because the different function for unicode stuff. Looks all right.
 [2009-11-02 17:57 UTC] pajoye@php.net
DId you reproduce the garbage in trunk on x64 and x86, ubuntu and windows? That's why I did not apply it yet.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 14:01:29 2024 UTC