http://www.perlmonks.org?node_id=145238

Squiddhartha has asked for the wisdom of the Perl Monks concerning the following question:

Hello! First time poster here, so please be gentle if I transgress. Consider the following short piece of code: 
#!/bin/perl
use GDBM_File;

# File 'voo' created with:
#tie %DBM, GDBM_File, 'voo', &GDBM_WRCREAT, 0644;
#$DBM{'goo'}='moo';
#untie %DBM;

sub DBMopenread {
    $DBREFread=tie %DBM, GDBM_File, $_[0], &GDBM_READER, 0644;
}
sub DBMcloseread {
    $DBREFread = undef; untie %DBM;
}

&DBMopenread('voo');
#$DBREFread=tie %DBM, GDBM_File, 'voo', &GDBM_READER, 0644;
$m=$DBM{'goo'};
print "$m\n";
&DBMcloseread("voo");

[download]
When run with the &DBMopenread call, under both Linux and Solaris, I see (the appropriate version of) this message: 
Argument "voo" isn't numeric in subroutine entry at /opt/perl/lib/5.6.
+1/sun4-solaris/GDBM_File.pm line 69.

[download]
However, if I comment out the &DBMopenread call and just use the direct tie statement... no errors. Can anyone shed light on this strange situation? I'm trying to eliminate some Apache error_log messages. Thank you!

Replies are listed 'Best First'.
Re: Mysterious GDBM_File error
by mattriff (Chaplain) on Feb 14, 2002 at 00:40 UTC
    What does line 69 of your GDBM_File.pm look like?

    I cut/pasted the code sample you gave and it ran for me with no errors or warnings (Perl 5.6.0 on FreeBSD, GDBM_File version 1.03).

    - Matt Riffle

    PS: You may/may not want to consider using "use strict" in your code. It's generally a good idea, but I'm not going to tell you what to do. :)

[reply]
      Line 69 is in the middle of GDBM_File.pm's AUTOLOAD routine: 
      sub AUTOLOAD {
    my($constname);
    ($constname = $AUTOLOAD) =~ s/.*:://;
    my $val = constant($constname, @_ ? $_[0] : 0);
    if ($! != 0) {
        if ($! =~ /Invalid/ || $!{EINVAL}) {
            $AutoLoader::AUTOLOAD = $AUTOLOAD;
            goto &AutoLoader::AUTOLOAD;
        }
        else {
            Carp::croak("Your vendor has not defined GDBM_File macro $
+constname, used");
        }
    }
    eval "sub $AUTOLOAD { $val }";
    goto &$AUTOLOAD;
}

      [download]
      Line 69 is the one beginning with my $val. I'm familiar with 'use strict' and do indeed use it on my big projects, but this is not my code -- it's an excerpt from the wreq work request system.
[reply]
[d/l]
[select]
Re: Mysterious GDBM_File error
by Speedy (Monk) on Feb 14, 2002 at 01:18 UTC
    I don't have a theoretical answer about the source of the problem; GDBM seems relatively undocumented. But I do have a workaround.

    Define your file
    $voo = "/somewhere/voo";
    somewhere before the subroutine call.

    Substitute the variable $voo for $_[0] in the DBMopenread subroutine -- it is a global variable, so the statement become:
    $DBREFread=tie %DBM, GDBM_File, $voo, &GDBM_READER, 0644;

    Leave the parameter out of the subroutine call, just:
    &DBMopenread;

    Seems to work. Of course you have to pay attention to the other instances of 'voo' versus the variable $voo.

    Sorry I don't have a more satisfactory "why," but you can get on with yur work.
[reply]
      Well, it's good to know that I'm not the only one stumped by this! Thank you very much for the workaround; now I have to decide whether to apply this within my wreq installation, or just live with the error message. (The DBMopenread call occurs pretty commonly within wreq, so this would be nontrivial.)
[reply]

Back to Seekers of Perl Wisdom