Turn off UTF8 flag on crypt ret val

crypt was not turning off the UTF8 flag on its return value.  On some
systems, such as VMS, it returns a string of random bytes, not neces-
sarily ASCII.  If the UTF8 flag is already turned on on its target
(the SV used to return the value), then the return value is scrambled.

Normally crypt’s target is its own, and never gets the UTF8 flag
turned on.  However, $lexical = crypt(...) gets optimised, such that
$lexical becomes the target of crypt, and crypt writes to it directly.
So it very well may have the UTF8 flag on already.

There are already tests in lex_assign.t that fail
on VMS because of this (see the thread that includes
<CA+vYcVyvq=j-vdWcODSfCjzM9-cYFYfY4hE-B1aWRRP4-=3KNA@mail.gom>), but
those tests are fragile, and this should be tested more explicitly.

1 files changed, 6 insertions, 1 deletions

diff --git a/t/op/crypt.t b/t/op/crypt.t
index f6caf85288..47e546d7ab 100644
--- a/t/op/crypt.t
+++ b/t/op/crypt.t
@@ -14,7 +14,7 @@ BEGIN {
         skip_all("crypt unimplemented");
     }
     else {
-        plan(tests => 4);
+        plan(tests => 6);
     }
 }
 
@@ -55,3 +55,8 @@ eval {$b = crypt($a, $alg."cd")};
 is($@, '',                   "downgrade to eight bit characters");
 is($b, crypt("a\xFF", $alg."cd"), "downgrade results agree");
 
+my $x = chr 256; # has to be lexical, and predeclared
+# Assignment gets optimised away here:
+$x = crypt "foo", ${\"bar"}; # ${\ } to defeat constant folding
+is $x, crypt("foo", "bar"), 'crypt writing to utf8 target';
+ok !utf8::is_utf8($x), 'crypt turns off utf8 on its target';