So we should remove locale-awareness then?
-Andrei
On Jan 4, 2007, at 5:15 AM, Matt Wilmas wrote:
Hi Andrei,
No, not really... :-) I agree with what you said. Even in
non-Unicode mode
or 5.2, it doesn't seem like making things locale aware which weren't
before
is a good idea (3rd party code that's relying on behavior, etc. which I
think was mentioned elsewhere).
Matt
----- Original Message -----
From: "Andrei Zmievski"
Sent: Wednesday, January 03, 2007
Matt, any replies to this?
-A
On Dec 22, 2006, at 9:53 AM, Andrei Zmievski wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
