see_args( @ENV{qw(TMPDIR TEMP TMP)} );
[download]

Whenever a non-existing hash or array element is used in anything but a simple context, it's autovivificated. The *default* is to autovivificate - it's just that the exceptions happen to be the most often used cases, so it's a surprise when perl autovivifies.

#!/usr/bin/perl

use strict;
use warnings;

my %hash;

sub X {}
my $x;

$x = exists $hash{key1};
printf "key1 %sautovivified\n",  exists $hash{key1} ? "" : "not ";

$x = $hash{key2};
printf "key2 %sautovivified\n",  exists $hash{key2} ? "" : "not ";

$x = exists $hash{key4}{key3};
printf "key3 %sautovivified\n",  exists $hash{key4}{key3} ? "" : "not 
+";
printf "key4 %sautovivified\n",  exists $hash{key4} ? "" : "not ";

($x) = @hash{key5};
printf "key5 %sautovivified\n",  exists $hash{key5} ? "" : "not ";

($x) = @hash{"key6", "key7"};
printf "key6 %sautovivified\n",  exists $hash{key6} ? "" : "not ";
printf "key7 %sautovivified\n",  exists $hash{key7} ? "" : "not ";

X($hash{key8});
printf "key8 %sautovivified\n",  exists $hash{key8} ? "" : "not ";

X(@hash{key9});
printf "key9 %sautovivified\n",  exists $hash{key9} ? "" : "not ";

X(@hash{"keyA","keyB"});
printf "keyA %sautovivified\n",  exists $hash{keyA} ? "" : "not ";
printf "keyB %sautovivified\n",  exists $hash{keyB} ? "" : "not ";  
__END__
key1 not autovivified
key2 not autovivified
key3 not autovivified
key4 autovivified
key5 not autovivified
key6 not autovivified
key7 not autovivified
key8 not autovivified
key9 autovivified
keyA autovivified
keyB autovivified
[download]

Perl --((8:>*

Wow, thanks for the examples. It would seem "simple usage" is not what people would assume it is. I will go file a bug report against PathTools, but it may be instructive to see how easy it is to fall into this trap. Here is the line of code in File::Spec::Win32.pm that caused me all the grief:

  $tmpdir = $_[0]->_tmpdir( @ENV{qw(TMPDIR TEMP TMP)},
                            'SYS:/temp',
                            'C:\system\temp',
                            'C:/temp',
                            '/tmp',
                            '/'  );
[download]

Sure looks innocent, huh? Of course the 'fix' will be to change the references to 'simple' ones,

  $tmpdir = $_[0]->_tmpdir( $ENV{TMPDIR},
                            $ENV{TEMP},
                            $ENV{TMP},
[download]

And in answer to Skeeve, yes, I am a "bug-magnet"

But I am not explicitly telling Perl to autovivify, rather I am (intending to) just reference the values, in this case using a slice.

Refer to my simpler example above. Using see_args( @foo{qw(BAR BAZ)} ); causes result:

at start: BAR '<absent>'
at end: BAR '<undef>'
[download]

But changing that to see_args( $foo{BAR}, $foo{BAZ} ); results in:

at start: BAR '<absent>'
at end: BAR '<absent>'
[download]

This is most perplexing to me.

Tell you what: It's perplexing to me the other way around!

Until 2 days ago I thought something like
if ($foo{'BAR'}) ...
would already vivify that hash entry.

But then I learned in the Chatter Box that it doesn't in perl 5.8 (or maybe a bit earlier).

And now I did a test. Compare the output

use Data::Dumper;
%foo=(BAZ=>1);
print Dumper \%foo if $foo{BAR} || 1;
print Dumper \%foo if @foo{BAR,BAZ} || 1;
[download]

Output:

$VAR1 = {
          'BAZ' => 1
        };
$VAR1 = {
          'BAZ' => 1
        };



use Data::Dumper;
%foo=(BAZ=>1);
print Dumper \%foo if call($foo{BAR});
print Dumper \%foo if call(@foo{BAR,BAZ});
sub call { return 1 }
[download]

Output:

$VAR1 = {
          'BAZ' => 1
        };
$VAR1 = {
          'BAR' => undef,
          'BAZ' => 1
        };


So it's really the fact that the slice is used in a subroutine call. When you replace call with print, autovivification does not happen

So now I ask myself: Is there a bug and you are certified bugfinder!? ;-)

---

s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e

This really has nothing to do with autovivification, you never attempted to define $ENV{TMPDIR}, and $ENV{TMPDIR} never existed (through either you or autovivification, unless it was really defined as an environment variable before you enter the program) before or after.

The first argument you passed in is undef, which failed the join. Not surprisingly, comment out printf obviously will get rid of the error. Here is part of your code without that function:

use strict;
use warnings;
use Data::Dumper;

    warn sprintf "In test, at start (1): TMPDIR '%s'\n",
        ! exists $ENV{TMPDIR} ?  '<absent>' : ! defined $ENV{TMPDIR} ?
+ '<undef>' : $ENV{TMPDIR};
print Dumper(@ENV{qw(TMPDIR TEMP TMP)});
[download]

Which prints:

$VAR1 = undef;
$VAR2 = 'C:\\DOCUME~1\\someone\\LOCALS~1\\Temp';
$VAR3 = 'C:\\DOCUME~1\\someone\\LOCALS~1\\Temp';
[download]

I think you missed the point of the post, which is "how is the variable $ENV{TMPDIR} being autovivified?" I am not caring that the value passed into the subroutine is undefined, since the environment variable is indeed not defined. But I do care that the variable outside the subroutine changes from '<absent>' to '<undef>'.

Update: My apologies! Forget what I have said, it was my observation was off, not yours. But it might be a better idea to demo your issue by using Data::Dumper.

use Data::Dumper;

use strict;
use warnings;
my  %foo = ( BAZ => 1 );
sub see_args { };

print Dumper(\%foo);
see_args( @foo{qw(BAR BAZ)} );
print Dumper(\%foo);
[download]

It prints:

$VAR1 = {
          'BAZ' => 1
        };
$VAR1 = {
          'BAZ' => 1,
          'BAR' => undef
        };
[download]

Yes, autovivification is in working.

Your observation was off. In your original post, you were confused by the fact that the $ENV{TMPDIR} "appears" to have a value as you saw it through that sprintf. No, you didn't see the value of $ENV{TMPDIR}. Your sprintf printed a constant "<absent>", not the value of $ENV{TMPDIR}.</strick>