The new printf implementation

php.internals

Matt W

19 years ago
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

Andrei Zmievski

19 years ago
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:

Andrei Zmievski

19 years ago
Matt, any replies to this? -A On Dec 22, 2006, at 9:53 AM, Andrei Zmievski wrote:

Matt W

19 years ago
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

Andrei Zmievski

19 years ago
So we should remove locale-awareness then? -Andrei On Jan 4, 2007, at 5:15 AM, Matt Wilmas wrote:

Matt W

19 years ago
Hi Andrei, I have no idea. :-) It doesn't really affect me personally that I can think of, so whatever you guys decide. I don't feel strongly either way... I just wanted to bring up the internal changes originally after the locale stuff created the bug with number_format() (maybe a couple others). In your first reply (weeks ago), you mentioned POSIX locales being deprecated in Unicode mode, and I assumed you were referring to the internal printf, but maybe you meant PHP's userland printf. Well, whichever version, I'm neutral on what to do. Oh, and to clarify that the locale-awareness wasn't "a good idea" in my last message, I meant as far as breaking things (internal or 3rd party), not just in general... Matt ----- Original Message ----- From: "Andrei Zmievski" Sent: Thursday, January 04, 2007

Andrei Zmievski

19 years ago
Yes, POSIX locales should not be used either in internal or userland printf() unless we're using en_US locale. -Andrei On Jan 5, 2007, at 6:15 AM, Matt Wilmas wrote:

Pierre Joye

19 years ago
Hello, On 1/5/07, Andrei Zmievski <andrei@gravitonic.com> wrote:
> Yes, POSIX locales should not be used either in internal or userland > printf() unless we're using en_US locale.
I agree. This change is unlucky and as far as I can see we fix our tree instead of restoring the old behaviors. I'm not sure why this decision was taken but I do not consider it as a good one, there is many other extensions out there who rely on the printf behavior, we cannot change it just for "fun". --Pierre