[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: jplesnik(a)redhat.com
          Reporter: bgz(a)twics.org
        QA Contact: extras-qa(a)fedoraproject.org
                CC: caillon+fedoraproject(a)gmail.com, iarnell(a)gmail.com,
                    jplesnik(a)redhat.com, kasal(a)ucw.cz,
                    mmaslano(a)redhat.com, mspacek(a)redhat.com,
                    perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
                    psabata(a)redhat.com, rhughes(a)redhat.com,
                    sandmann(a)redhat.com, spotrh(a)gmail.com
  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...


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608

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

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

Jitka Plesnikova <jplesnik(a)redhat.com&gt; changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
           Doc Type|---                         |If docs needed, set a value
             Status|NEW                         |CLOSED
        Last Closed|                            |2022-02-17 11:42:53



--- Comment #1 from Jitka Plesnikova <jplesnik(a)redhat.com&gt; ---
This behavior is describe in perldoc for 'exists':


Note that the EXPR can be arbitrarily complicated as long as the 
final operation is a hash or array key lookup or subroutine
name:

    if (exists $ref->{A}->{B}->{$key})  { }
    if (exists $hash{A}{B}{$key})       { }

    if (exists $ref->{A}->{B}->[$ix])   { }
    if (exists $hash{A}{B}[$ix])        { }

    if (exists &{$ref->{A}{B}{$key}})   { }

Although the most deeply nested array or hash element will not
spring into existence just because its existence was tested, any 
intervening ones will. Thus "$ref->{"A"}" and
"$ref->{"A"}->{"B"}" will spring into existence due to
the
existence test for the $key element above. This happens anywhere
the arrow operator is used, including even here:

    undef $ref;
    if (exists $ref->{"Some key"})    { }
    print $ref;  # prints HASH(0x80d3d5c)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608

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

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



--- Comment #2 from Petr Pisar <ppisar(a)redhat.com&gt; ---
This feature is called "autovivification". See perlref POD.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608

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

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



--- Comment #3 from BZ <bgz(a)twics.org&gt; ---
Thanks for that. Even though semantically it seems like it SHOULD be a bug, for
better or worse at least it's not something unexpected. I just didn't find any
reference to that behavior in the documents I checked. Thanks!


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2055608