Numifying a 0x string evaluates the hex number #17062
Comments
From @GrinnzWhen starting with a string that looks like '0xFF', numifying it should 5.28:
5.30:
It also seems to have had this behavior way back in 5.6:
-Dan |
From @TuxOn Thu, 27 Jun 2019 07:35:45 -0700, "Dan Book \(via RT\)"
Interesting $ perl-all -le 'print "0xFF" + 0' === base/perl5.6.0 5.006 x86_64-linux ... 0 all the way to === base/tperl5.28 5.028001 x86_64-linux-thread-multi-ld I have more perl's at home -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @sisyphusI expect this will be due to commit For me, strtod() does not understand the '0b' prefix and simply numifies C:\>perl -MPOSIX -le "@x=POSIX::strtod('0b11111'); print for @x;" But it does understand the '0x' prefix: C:\>perl -MPOSIX -le "@x=POSIX::strtod('0xff'); print for @x;" Cheers, On Fri, Jun 28, 2019 at 12:50 AM H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
|
From @sisyphusOn Thu, 27 Jun 2019 18:14:38 -0700, sisyphus359@gmail.com wrote:
Seems to me that it's maybe a bit silly to be handing hex *integer* strings to strtod() when perl assigns hex integer barewords to IV. It's ok when the value fits in both the IV and the NV, but when IV-precision exceeds NV-precision we can get results that don't DWIM all that well: C:\> perl -le "print 'wtf' if 0xfffffffffffffff == '0xfffffffffffffc0' + 0;" (That's on perl-5.30.0, ivsize and nvsize both == 8.) It might make better sense if, in such cases, the hex integer string was handed over to srtol/strtoll. Cheers, |
From @ikegamiChanging this means changing Scalar::Util::looks_like_number. Would that Also, it could break things that use the regex patterns provided in On Thu, Jun 27, 2019 at 10:35 AM Dan Book (via RT) <
|
From @sisyphusOn Thu, 27 Jun 2019 22:34:32 -0700, ikegami@adaelis.com wrote:
I agree that looks_like_number()also needs to be thought about. Perl's current behaviour is to issue the "isn't numeric" warning when "0xff"+0 is evaluated. Cheers, |
From @tonycozOn Fri, 28 Jun 2019 03:36:08 -0700, sisyphus@cpan.org wrote:
I don't think looks_like_number() needs to change - I think C<"0xff"> needs to return to numerically evaluating as 0, pre the attached. Tony |
From @tonycoz0001-perl-134230-don-t-interpret-0x-0b-when-numifying-str.patchFrom e3299a45a90066de1fc387fd0f40cdd81571d3c8 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Tue, 20 Aug 2019 15:43:05 +1000
Subject: (perl #134230) don't interpret 0x, 0b when numifying strings
---
numeric.c | 9 +++++++++
t/op/int.t | 5 ++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/numeric.c b/numeric.c
index f5eadc8173..fae2eb3c6d 100644
--- a/numeric.c
+++ b/numeric.c
@@ -1551,6 +1551,15 @@ Perl_my_atof3(pTHX_ const char* orig, NV* value, const STRLEN len)
if ((endp = S_my_atof_infnan(aTHX_ s, negative, send, value)))
return endp;
+ /* strtold() accepts 0x-prefixed hex and in POSIX implementations,
+ 0b-prefixed binary numbers, which is backward incompatible
+ */
+ if ((len == 0 || len >= 2) && *s == '0' &&
+ (isALPHA_FOLD_EQ(s[1], 'x') || isALPHA_FOLD_EQ(s[1], 'b'))) {
+ *value = 0;
+ return (char *)s+1;
+ }
+
/* If the length is passed in, the input string isn't NUL-terminated,
* and in it turns out the function below assumes it is; therefore we
* create a copy and NUL-terminate that */
diff --git a/t/op/int.t b/t/op/int.t
index 7e936da68d..b730ab2672 100644
--- a/t/op/int.t
+++ b/t/op/int.t
@@ -7,7 +7,7 @@ BEGIN {
require Config;
}
-plan 17;
+plan 19;
# compile time evaluation
@@ -83,3 +83,6 @@ SKIP:
cmp_ok($x, "==", int($x), "check $x == int($x)");
}
}
+
+is(1+"0x10", 1, "check string '0x' prefix not treated as hex");
+is(1+"0b10", 1, "check string '0b' prefix not treated as binary");
--
2.11.0
|
From @karenetheridgeOn Mon, Aug 19, 2019 at 10:53 PM Tony Cook via RT
Why did this behaviour change? Was it intentional or a side effect? commit ce6f496 (HEAD, refs/bisect/bad) PATCH: [perl #41202] text->float gives wrong answer This changes to use Perl_strtod() when available, and that turns out to S_mulexp10() is removed from embed.fnc to avoid repeating the James Keenan fixed a file permissions problem originally introduced by |
From @sisyphusOn Mon, Aug 26, 2019 at 5:23 AM Karen Etheridge <perl@froods.org> wrote:
An unintended side effect. Cheers, |
From @tonycozOn Mon, 19 Aug 2019 22:53:04 -0700, tonyc wrote:
Applied as 14d26b4. Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
From @karenetheridgeExcellent! On Sun, Aug 25, 2019 at 5:29 PM Tony Cook via RT
|
Migrated from rt.perl.org#134230 (status was 'pending release')
Searchable as RT134230$
The text was updated successfully, but these errors were encountered: