Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27189
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gravitonic.com from 204.11.219.139 cause and error)
In-Reply-To: <020801c725ce$fe9fe190$0201a8c0@pc1>
References: <020801c725ce$fe9fe190$0201a8c0@pc1>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <a5355eec6f6a88ac8abe33b55a723acd@gravitonic.com>
Content-Transfer-Encoding: 7bit
Cc: <internals@lists.php.net>
Date: Fri, 22 Dec 2006 09:53:37 -0800
To: "Matt Wilmas" <php_lists@realplain.com>
Subject: Re: [PHP-DEV] The new printf implementation
From: andrei@gravitonic.com (Andrei Zmievski)

Especially since POSIX locales are deprecated in Unicode mode. I really 
don't think printf() should use locale-aware formatting by default.

-Andrei

On Dec 22, 2006, at 5:42 AM, Matt Wilmas wrote:

> 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
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php