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
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 withnumber_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'ssprintf()), 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
Matt, any replies to this?
-A
Especially since POSIX locales are deprecated in Unicode mode. I
really don't thinkprintf()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 withnumber_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'ssprintf()), 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
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
Especially since POSIX locales are deprecated in Unicode mode. I
really don't thinkprintf()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 withnumber_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'ssprintf()), 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
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, 2007Matt, any replies to this?
-A
Especially since POSIX locales are deprecated in Unicode mode. I
really don't thinkprintf()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 withnumber_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'ssprintf()), 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
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
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
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 withnumber_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, 2007So 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
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