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

Reply via email to