From 9ac12f1967e091b504ac426a70fb41af0d9d44c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppisar@redhat.com>
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 <sisyphus1@optusnet.com.au>
    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 <tony@develop-help.com>
    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