[perl #91834] utf8::decode does not respect copy-on-write

utf8::decode was not respecting copy-on-write, but simply modify-
ing the PV (the scalar’s string buffer) in place, causing problems
with hashes:

my $name = "\x{c3}\x{b3}";
my ($k1) = keys %{ { $name=>undef } };
my $k2 = $name;
utf8::decode($k1);
utf8::decode($k2);
print "k1 eq k2 = '", $k1 eq $k2, "'\n";
my $h = { $k1 => 1, $k2 => 2 };
print "{k1} '", $h->{$k1}, "'\n";
print "{k2} '", $h->{$k2}, "'\n";

This example (from the RT ticket) shows that there were two hash ele-
ments with the same key.

As of this commit, the hash only has one element.

1 files changed, 12 insertions, 0 deletions

diff --git a/lib/utf8.t b/lib/utf8.t
index ae81ccdc46..b13bb5377d 100644
--- a/lib/utf8.t
+++ b/lib/utf8.t
@@ -427,6 +427,18 @@ SKIP: {
 }
 
 {
+    # Make sure utf8::decode respects copy-on-write [perl #91834].
+    # Hash keys are the easiest way to test this.
+    my $name = "\x{c3}\x{b3}";
+    my ($k1) = keys %{ { $name=>undef } };
+    my $k2 = $name;
+    utf8::decode($k1);
+    utf8::decode($k2);
+    my $h = { $k1 => 1, $k2 => 2 };
+    is join('', keys $h), $k2, 'utf8::decode respects copy-on-write';
+}
+
+{
     my $a = "456\xb6";
     utf8::upgrade($a);