[Bug 2055608] New: Perl 5.32.1 Incorrectly Processes Hash Key Existence in Two-Dimensional Hashes

https://bugzilla.redhat.com/show_bug.cgi?id=2055608

Bug ID: 2055608
           Summary: Perl 5.32.1 Incorrectly Processes Hash Key Existence
                    in Two-Dimensional Hashes
           Product: Fedora
           Version: 34
          Hardware: x86_64
                OS: Linux
            Status: NEW
         Component: perl
          Severity: medium
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail]
  Target Milestone: ---
    Classification: Fedora

Description of problem:

This appears to be a basic Perl runtime error. Checking for the existence of an
element in a two-dimensional hash has the side-effect of bringing into
existence a hash entry with the first index value. It's easier to see in code:

#!/usr/bin/perl

%X = ();
@I = ("1","2","3");
$N = 0;
foreach $D (@I)
{
    $N++ if (exists($X{$D}{"A"}));
    printf "K: %u\n",scalar(keys %X);
}
printf "N: %u\n",$N;

Running the code inexplicably generates this output:

K: 1
K: 2
K: 3
N: 0

Version-Release number of selected component (if applicable):

5.32.1 with 51 patches applied by Fedora (this is the current package version
available in Fedora 34)

How reproducible:

100%

Steps to Reproduce:
1. Run the above code
2.
3.

Actual results:

K: 1
K: 2
K: 3
N: 0

Expected results:

K: 0
K: 0
K: 0
N: 0

Additional info:

The problem only seems to arise with multi-dimensional hashes. Code such as:

#!/usr/bin/perl

%X = ();
@I = ("1","2","3");
$N = 0;
foreach $D (@I)
{
    $N++ if (exists($X{$D}));
    printf "K: %u\n",scalar(keys %X);
}
printf "N: %u\n",$N;

behaves as expected, returning:

K: 0
K: 0
K: 0
N: 0

I find it difficult to believe that this bug, if it is a bug rather than a
not-very-well-documented "feature," has not been noticed before, but perhaps
nothing critical depended upon it? But then again, something critical might, in
which case this package version dates back to 23 June 2021...