Blame Encode-2.96-Fix-https-rt.cpan.org-Ticket-Display.html-id-124399.patch

e0d0841
From cfaedb2beda37cbc3575ee818c3c83ea87673c32 Mon Sep 17 00:00:00 2001
e0d0841
From: Karl Williamson <khw@cpan.org>
e0d0841
Date: Wed, 14 Feb 2018 15:47:46 -0700
e0d0841
Subject: [PATCH] Fix https://rt.cpan.org/Ticket/Display.html?id=124399
e0d0841
MIME-Version: 1.0
e0d0841
Content-Type: text/plain; charset=UTF-8
e0d0841
Content-Transfer-Encoding: 8bit
e0d0841
e0d0841
Encode 2.95 broke this module, which is testing for a particular warning
e0d0841
message.  It was not my intent to change any part of the API with the
e0d0841
commits that comprise 2.95, and it turns out that the message is
e0d0841
different only in one or two perl versions where an interaction with a
e0d0841
deprecation caused the new message to be displayed.
e0d0841
e0d0841
The commit here just keeps the old code being used into the 5.27 series.
e0d0841
It probably could work starting in 5.27.2, but its easier to use a
e0d0841
marker of the existence of a newer function, and since the affected
e0d0841
versions are all development releases, I went with the marker.
e0d0841
e0d0841
Signed-off-by: Petr Písař <ppisar@redhat.com>
e0d0841
---
e0d0841
 Encode.xs | 2 +-
e0d0841
 1 file changed, 1 insertion(+), 1 deletion(-)
e0d0841
e0d0841
diff --git a/Encode.xs b/Encode.xs
e0d0841
index 91c5257..13eb15d 100644
e0d0841
--- a/Encode.xs
e0d0841
+++ b/Encode.xs
e0d0841
@@ -387,7 +387,7 @@ strict_utf8(pTHX_ SV* sv)
e0d0841
 }
e0d0841
 
e0d0841
 /* Modern perls have the capability to do this more efficiently and portably */
e0d0841
-#ifdef is_utf8_string_loc_flags
e0d0841
+#ifdef utf8n_to_uvchr_msgs
e0d0841
 # define CAN_USE_BASE_PERL
e0d0841
 #endif
e0d0841
 
e0d0841
-- 
e0d0841
2.13.6
e0d0841