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

Reply via email to