Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.142.136.132 cause and error)
Message-ID: <020801c725ce$fe9fe190$0201a8c0@pc1>
To: <internals@lists.php.net>
Date: Fri, 22 Dec 2006 07:42:16 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: The new printf implementation
From: php_lists@realplain.com ("Matt Wilmas")

Hi all,

A couple questions regarding the printf changes (internal and userland) a
couple weeks ago...

Now the internal %f, %g, and %G are locale-aware, which they weren't before,
right?  Is this how they're supposed to be and simply weren't before?  (The
locale changes caused Bug #39873 with number_format(), etc.)  In userland
*printf(), %f (as always), %g, and %G are also locale-aware, but, like
"internally," %e and %E are not?  None of it really affects me, just wanting
to verify desired behavior. :-)

Second thing is about the g/G specifiers, especially now that they're in
userland.  It's my understanding that scientific notation should be used if
the exponent is < -4 or >= the precision.  So why with printf('%.6g',
1234567890) do I get "1234570000" instead of the expected "1.23457e+9"?  The
former just looks wrong.  (One more digit triggers scientific notation.)
Using:

ini_set('precision', 6);
echo (double) 1234567890;

it comes out as expected, both on Windows (where zend_sprintf() appears to
use the system's sprintf()), and on my Linux host.

The same issue exists in Unicode mode, with double->Unicode conversion,
which makes things different depending on unicode.semantics...

It's a simple fix to make g/G work the way I thought (and think) they
should.  Thoughts?


Thanks,
Matt