From 9ac12f1967e091b504ac426a70fb41af0d9d44c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Mon, 3 Jun 2019 15:43:31 +0200 Subject: [PATCH] Adapt tests to Perl 5.30 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Perl started to understand a numerical value of hexadecimal strings like '0xF'. This happens since Perl commit: commit ce6f496d720f6206455628425320badd95b07372 (HEAD, refs/bisect/bad) Author: sisyphus Date: Wed Aug 1 22:33:38 2018 +1000 PATCH: [perl #41202] text->float gives wrong answer This changes to use Perl_strtod() when available, and that turns out to be the key to fixing this bug. S_mulexp10() is removed from embed.fnc to avoid repeating the complicated prerequisites for defining Perl_strtod(). This works because this static function already was defined before use in numeric.c, and always called in full form without using a macro. James Keenan fixed a file permissions problem originally introduced by this commit, but the fix has been squashed into it. But it was recognized as a bug and the behavior was restored with: commit 14d26b44a1d7eee67837ec0ea8fb0368ac6fe33e Author: Tony Cook Date: Tue Aug 20 15:43:05 2019 +1000 (perl #134230) don't interpret 0x, 0b when numifying strings Petr Písař: And we ported it to 5.30.0. --- t/tlib/AssertTest.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/tlib/AssertTest.pm b/t/tlib/AssertTest.pm index 42fa860..d58890c 100644 --- a/t/tlib/AssertTest.pm +++ b/t/tlib/AssertTest.pm @@ -34,7 +34,7 @@ sub test_numericness { my %tests = ( 1 => 't', 0 => 't', - '0xF00' => 'f', # controversial? but if you +=10 then it's == 10 + '0xF00' => ($] gt '5.029001' && $] lt '5.030000') ? 't' : 'f', '15e7' => 't', '15E7' => 't', "not 0" => 'f', -- 2.21.0