Re: The new printf implementation

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