Re^3: untie tied hash fails mysteriously

Is that sub really coded without strict and returning globals?:

sub svhash {    
    ($db, $hm, $makedb, $duplicates, $bdbtype) = @_;
    $makedb ||= 0;        
    $duplicates ||= '';    
    $bdbtype ||= 'hash';    
    my %h;                               
    ($dbhandx, $fail) = ("", ""); ##<<<<<<<<<<<<<
...
    return ($dbhandx, $fail);     ##<<<<<<<<<<<<<
}
[download]

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^3: untie tied hash fails mysteriously Download Code

Replies are listed 'Best First'.
Re^4: untie tied hash fails mysteriously by Pstack (Scribe) on Sep 12, 2011 at 22:37 UTC
Not entirely, but well spotted. I cannot recall full rationale for that old 'unusual' coding, but may have to revisit it all again ... but under complex test conditions since it sits at hub of mission critical stuff. The return & other vars have module scope, probably to share with internal subs, and where the external subs have a standardised layout. I see svhash() only calls 1 internal and so may not need module scoping of vars so often! `package DB::DBctrl; #use strict; our @EXPORT_OK = qw(svhash svdb mvdbsub mvdbhead);# externals my ($dbhandx, $fail, etc, ...) = ("","", etc, ...); sub svhash { return ($dbhandx, $fail); }` [download] I think I would have interspersed compilations to the test stage where final 'use strict'-miscompile only due to the ("BerkeleyDB::HASH" etc) barewords it couldn't handle. But the exact ramifications escape me at the moment. However, even module scope for a returned ref is starting to give me the jitters ... thanks very much ...	[reply] [d/l]
Re^4: untie tied hash fails mysteriously by Pstack (Scribe) on Sep 14, 2011 at 04:52 UTC
`sub svhash { ... my ($dbhandx, $fail) = ("", ""); ##<<<<<<<<<<<<< ... return ($dbhandx, $fail); ##<<<<<<<<<<<<< }` [download] Altering scope of $dbhandx to svhash() instead of parent module did not, unfortunately, solve the problem. Potential nasty side effects of that mistake were never struck due to a higher level wrapper managing mutual exclusivity of processes that might clash. Lucky perhaps.	[reply] [d/l]