Referring to floating $x under locale changes its string representation #11872
Comments
From @khwilliamsonThis is a bug report for perl from khw@karl.(none), In lib/locale.t $x is set to 1.23 and then used on the rhs of various Flags: Site configuration information for perl 5.15.6: Configured by khw at Mon Jan 16 10:15:54 MST 2012. Summary of my perl5 (revision 5 version 15 subversion 6) configuration: Locally applied patches: @INC for perl 5.15.6: /home/khw/blead/lib/perl5/site_perl/5.15.6/i686-linux-thread-multi-64int-ld Environment for perl 5.15.6: PATH=/home/khw/bin:/home/khw/print/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/usr/games:/home/khw/cxoffice/bin |
From @cpansproutOn Mon Jan 16 11:04:04 2012, public@khwilliamson.com wrote:
I think that is why $# was deprecated and removed. It breaks number <-> -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 05/12/2013 01:44 PM, Nicholas Clark wrote:
It turns out that we already keep track of if we are in the C locale or The attached draft patch demonstrates this. It also appears to fix It does this by not setting SvPOK when in the scope of 'use locale'. $a = 1.2; sets $a to "1,2" if the current locale calls for that radix, where it By not setting SvPOK, the NV remains an NV, and if a stringified version It also has the side effect that the radix in every SVNV will be a dot, I believe that additionally, within the scope of 'use locale', any PVNV I'm not familiar enough with this part of Perl to know if there is The problem with this patch is that it breaks code that has come to rely lib/version/t/07locale.t It doesn't do a 'use locale', and even if one is added, one test fails Thus, this patch fixes some problems, and I believe makes locales work |
From @khwilliamson0008-XXX-draft-patch.patchFrom 02dc6aa79842af16c4129a89d249de100cbb5ff0 Mon Sep 17 00:00:00 2001
From: Karl Williamson <[email protected]>
Date: Mon, 13 May 2013 07:35:35 -0600
Subject: [PATCH 8/8] XXX draft patch
---
sv.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/sv.c b/sv.c
index 3736ba8..4a39607 100644
--- a/sv.c
+++ b/sv.c
@@ -2894,6 +2894,7 @@ Perl_sv_2pv_flags(pTHX_ SV *const sv, STRLEN *const lp, const I32 flags)
Move(ptr, s, len, char);
s += len;
*s = '\0';
+ SvPOK_on(sv);
}
else if (SvNOK(sv)) {
if (SvTYPE(sv) < SVt_PVNV)
@@ -2907,7 +2908,35 @@ Perl_sv_2pv_flags(pTHX_ SV *const sv, STRLEN *const lp, const I32 flags)
/* The +20 is pure guesswork. Configure test needed. --jhi */
s = SvGROW_mutable(sv, NV_DIG + 20);
/* some Xenix systems wipe out errno here */
- Gconvert(SvNVX(sv), NV_DIG, 0, s);
+
+#ifndef USE_LOCALE_NUMERIC
+ Gconvert(SvNVX(sv), NV_DIG, 0, s);
+ SvPOK_on(sv);
+#else
+ /* Gconvert uses the current locale. That's what we want if we're
+ * supposed to be using locales. But if not, we want the result
+ * based on the C locale, so we need to change to the C locale
+ * during the Gconvert and then change back. But if we're already
+ * in the C locale (PL_numeric_standard), no need to do any
+ * changing */
+ if (PL_numeric_standard || IN_LOCALE_RUNTIME) {
+ Gconvert(SvNVX(sv), NV_DIG, 0, s);
+ }
+ else {
+ char *loc = savepv(setlocale(LC_NUMERIC, NULL));
+ setlocale(LC_NUMERIC, "C");
+ Gconvert(SvNVX(sv), NV_DIG, 0, s);
+ setlocale(LC_NUMERIC, loc);
+ Safefree(loc);
+ }
+
+ /* The stringification should not "stick" if we are in locales, as
+ * a run-time change of the locale, or exiting the 'use locale'
+ * scope may require a different stringification */
+ if (! IN_LOCALE_RUNTIME) {
+ SvPOK_on(sv);
+ }
+#endif
RESTORE_ERRNO;
while (*s) s++;
}
@@ -2952,7 +2981,6 @@ Perl_sv_2pv_flags(pTHX_ SV *const sv, STRLEN *const lp, const I32 flags)
*lp = len;
SvCUR_set(sv, len);
}
- SvPOK_on(sv);
DEBUG_c(PerlIO_printf(Perl_debug_log, "0x%"UVxf" 2pv(%s)\n",
PTR2UV(sv),SvPVX_const(sv)));
if (flags & SV_CONST_RETURN)
--
1.8.1.3
|
From @nwc10On Mon, May 13, 2013 at 08:59:19AM -0600, Karl Williamson wrote:
Nice to know.
Yes, this seems like a sane approach. I can't spot any real flaws yet.
I am not familiar with it either. And, as you say, what we have now leaks $ cat locale.pl use POSIX ':locale_h'; $a = 3.14; $b = $b = "$a" if shift; setlocale(LC_ALL, "hr_HR"); use locale; print $a, "\n"; __END__ in that if C<use locale> is supposed to be affecting numeric conversions But that one feels harder to fix. Seems that one has to rid all the SvPV* Which feels like it's going to be ugly. To the point that I'm not sure if
We're allowed to be wrong, and correct our mistakes. Although generally it helps when doing this that it's clear that the new Nicholas Clark |
From @LeontOn Mon, May 13, 2013 at 4:59 PM, Karl Williamson
This all sounds sensible, however
I think you mean any SvNOK PVNV. PVNV can also contain cached. Also, you're suggesting that in: perl -MDevel::Peek -E 'my $num = "1.2"; log $num; say Dump $num;' the string "1.2" should be printed as a "1,2" because the variable
That's just wrong IMO. Leon |
From @ap* Nicholas Clark <nick@ccl4.org> [2013-05-13 21:55]:
This is a case where if the initial SV type were marked as a canonical, Regards, |
From @khwilliamsonOn 05/13/2013 06:25 PM, Aristotle Pagaltzis wrote:
I believe so |
From @nwc10On Thu, May 16, 2013 at 08:58:27AM -0600, Karl Williamson wrote:
No. Certainly not directly. Knowing that something is canonically a number For example $a = 3.14; Should that match? If locales are affecting stringification, and that is running within the But that then means that the call to SvPV() [or equivalent] within the Nicholas Clark |
From @khwilliamsonOn 05/13/2013 06:22 PM, Leon Timmermans wrote:
Actually, I'm not suggesting that. I ran this code with my patch perl -MPOSIX -MDevel::Peek -E 'POSIX::setlocale(POSIX::LC_ALL, This is one of those places where not having proper types is
I presume you mean the test is just wrong.
|
From @khwilliamsonOn 05/13/2013 01:50 PM, Nicholas Clark wrote:
My patch fixes this.
I believe you are talking about the case $a = 3.14; In that case my patch doesn't work, because $a is set POK because it is What I've since done to fix that is to change the eight macros that are /* Within locales, an NOK scalar isn't considered POK, thus forcing That forces the SVPV macros to call sv_2pv_flags() each time the
|
From @nwc10On Thu, May 16, 2013 at 10:26:42AM -0600, Karl Williamson wrote:
That approach starts to make me feel very uncomfortable. =for apidoc Am|U32|SvPOK|SV* sv it does change behaviour since 5.000, and contradicts this comment: #define SVf_POK 0x00000400 /* has valid public pointer value */
Yes, one has to end up with that approach. The alternative, which at the I can't see a way of doing this without more complexity. Nicholas Clark |
From @khwilliamsonOn 05/18/2013 02:47 AM, Nicholas Clark wrote:
Me neither. I'm fine with doing it as you suggest. My scheme was an I do believe, however, that we should issue a statement deprecating any |
From @janduboisI'm slightly confused by this discussion. AFAICT, there are currently Steffen and me believe that implicit stringification should always use Nicholas and Karl seem to be discussing implementation details on how I find the implementation discussion premature while there is no Cheers, |
From @rjbs* Jan Dubois <jand@activestate.com> [2013-05-21T13:41:29]
Implicit stringification in what sense? With LC_NUMERIC in effect, we promise Did I miss a detail somewhere? (Apologies for my late arrival here.) -- |
From @rjbs* Karl Williamson <public@khwilliamson.com> [2013-05-21T11:43:50]
Nicholas was suggesting not caching locale-stringified strings for numbers.
Is this something we can plausibly do? I think it's the sort of thing that At any rate, I am in favor of this to the extent that we don't break everything -- |
From @janduboisOn Sun, Jun 9, 2013 at 7:21 AM, Ricardo Signes
Sorry, it was my incomplete reading of perllocale.pod that led me to | Output produced by print() is also affected by the current locale: it If the output from print() corresponds to what you get from printf() But anyways, the next sentence, and the examples further down make it So I continue to consider this a bad language design decision, but Cheers, PS: string eval with interpolated floating point numbers is already |
From @rjbs* Jan Dubois <jand@activestate.com> [2013-06-10T04:07:32]
...and sorry about my reply, to which you're replying, as it was late to the
I agree that it is a bad design. I really have very little idea how widely Perhaps I can wrangle some information on that. I'll also look at
I have totally hit this. :-( -- |
From @khwilliamsonOn 06/09/2013 08:27 AM, Ricardo Signes wrote:
I will work on a patch to do this. I agree with Jan and Dr. Ruud that this is a poorly designed portion of
What I meant was adding something to perldelta and perhack, and perhaps "Because of limitations of the C language, various undocumented I don't see how we can generally make it so that warnings get generated |
From @cpansproutOn Sun Jun 16 12:16:11 2013, public@khwilliamson.com wrote:
perlbug@perl.org, please. :-) -- Father Chrysostomos |
From @jkeenanOn Mon Jun 10 15:00:45 2013, perl.p5p@rjbs.manxome.org wrote:
Is this the same problem as |
From @cpansproutOn Sun Jun 16 17:40:05 2013, jkeenan wrote:
No, I don’t think so. That one has to do with constant folding, and -- Father Chrysostomos |
From @khwilliamsonOn 06/16/2013 08:18 PM, Father Chrysostomos via RT wrote:
Also note that the author of #82418 expects that you don't need a 'use |
From @khwilliamsonFixed by b127e37 |
From [Unknown Contact. See original ticket]Fixed by b127e37 |
|
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#108378 (status was 'resolved')
Searchable as RT108378$
The text was updated successfully, but these errors were encountered: