# The new printf implementation - Thread: https://externals.io/message/27179 - Original archive: https://news-web.php.net/php.internals/27179 - Started by Matt Wilmas on 2006-12-22T13:42:16+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #27179 — Matt Wilmas — 2006-12-22T13:42:16+00:00 URL: https://externals.io/message/27179#27179 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 --- ## #27189 — Andrei Zmievski — 2006-12-22T17:53:37+00:00 URL: https://externals.io/message/27179#27189 · In reply to: #27179 Especially since POSIX locales are deprecated in Unicode mode. I really don't think `printf()` should use locale-aware formatting by default. -Andrei > 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 --- ## #27249 — Andrei Zmievski — 2007-01-03T18:52:13+00:00 URL: https://externals.io/message/27179#27249 · In reply to: #27189 Matt, any replies to this? -A > Especially since POSIX locales are deprecated in Unicode mode. I > really don't think `printf()` should use locale-aware formatting by > default. > > -Andrei > > > > > […] --- ## #27259 — Matt Wilmas — 2007-01-04T13:15:03+00:00 URL: https://externals.io/message/27179#27259 · In reply to: #27249 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 > > > > > […] --- ## #27260 — Andrei Zmievski — 2007-01-04T17:19:47+00:00 URL: https://externals.io/message/27179#27260 · In reply to: #27259 So we should remove locale-awareness then? -Andrei > 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 > > > […] --- ## #27280 — Matt Wilmas — 2007-01-05T14:15:53+00:00 URL: https://externals.io/message/27179#27280 · In reply to: #27260 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 > So we should remove locale-awareness then? > > -Andrei > > > > > […] --- ## #27287 — Andrei Zmievski — 2007-01-05T17:31:34+00:00 URL: https://externals.io/message/27179#27287 · In reply to: #27280 Yes, POSIX locales should not be used either in internal or userland `printf()` unless we're using en_US locale. -Andrei > 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 > > > […] --- ## #27302 — Pierre — 2007-01-06T15:55:53+00:00 URL: https://externals.io/message/27179#27302 · In reply to: #27287 Hello, > 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