Yes, after I posted, I realized that I hadn't addressed the multi-level hash issue. I didn't pursue it because I was sure it didn't matter. However, I did some testing and was shocked to find that Perl's autovivification can trigger a tied object's STORE method. I guess I shouldn't have been shocked.
So, yes, you can access a key in an unusual way and cause things to be created, unfortunately. I've long (very long) wanted a pragma to disable autovivification and this makes me want it that much more.
However, if you just attempt to fetch a single item (key or value) from the registry with Win32::TieRegistry, then it won't create anything in the registry.
Trying to fetch something that doesn't exist and using it directly in an lvalue context (such as chaining another fetch onto it) can cause stuff to be created. And, as I've noted elsewhere, exists has no magic powers for preventing such autovivification. It can prevent a sneaky lvalue context from suprising you (exactly the same as scalar or any number of other things can do).
But simply avoiding an lvalue context is also enough. For example:
my $key= $Registry->{"..."};
Or even:
if( $Registry->{"..."} ) {
is never going to create anything in the registry.
Update: I should add an option to the module to die if you try to create by assigning an empty hash ref because that would prevent autovivification.
- tye
In reply to Re^3: In Win32::TieRegistry, what is the best way to tell if a registry variable exists? (STORE)
by tye
in thread In Win32::TieRegistry, what is the best way to tell if a registry variable exists?
by DrWhy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |