Hi,

Sample code:

###
use strict;
use warnings;

sub getRefHash
{
    return { b =>  2 };           
}

my $refHash;

$refHash = $refHash || getRefHash();
$refHash-> {a} = 1;

print "$_=$refHash-> {$_}\n" foreach (keys(%$refHash));
###

Well, obviously my real code was a lot bigger and doing something 
entirely different, but this illustrates the problem...:-)

Running this prints:

c:\tmp> perl x.pl
a=1
b=2

However, I happened to be debugging my code using the PDK debugger, 
merrily stepping line for line. Focused on another problem I didn't pay 
attention to some details, but end result was that at the end of the 
program I had a broken $refHash and I had no idea why; debugging the 
sample program shows that it prints only 'a=1'.

As it turns out, if the debugger is displaying the '$refHash = ...' line 
as the next line to execute, the 'Proximity' window helpfully shows some 
values, in particular it shows that at present '$refHash-> {a]' evaluates 
to "", i.e. undef. But, as I understand it, by doing that, it causes 
auto-vivification and the $refHash actually becomes a hash reference, 
whereas it in normal conditions is still undef. When stepping over the 
line, it won't do the call to getRefHash(), and I don't get what I expect.

Well, at least this is my take on it...is this correctly understood?

I suppose the question goes to ActiveState (mostly Jan I guess :-), do 
you agree that this should be termed a debugger bug? It is a sort of an 
unexpected/unwanted side-effect...If so, should I file a bug report or 
is this post enough?

Thanks,

ken1
_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs