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

I hope this is a reasonable question to ask here. I've tried searching around for quite some time, but to no avail.

I used h2xs to generate the framework for a Perl module from a C header file (the first time I've ever done this). One the features automatically given to me is the ability to access #define'd constants from the C .h header file. This generated code goes into one package. That package appears to make the #define'd constants available as simple subroutines using (in part) AUTOLOAD.

From another package, I 'use' the package with the #define'd constants. When I attempt to access any of the #define'd constants, I do indeed get the appropriate value returned. However, I also get the following warning:

Prototype mismatch: sub CrashDump::dumpsys::CDUMP_MAGIC vs () at CrashDump/blib/lib/CrashDump/dumpsys.pm line 114 (#1) (S unsafe) The subroutine being declared or defined had previously + been declared or defined with a different function prototype.
As best I can tell, this is in part related to the following section of the AUTOLOAD routine in dumpsys.pm (an h2xs-generated file):
{ no strict 'refs'; # Fixed between 5.005_53 and 5.005_61 if ($] >= 5.00561) { *$AUTOLOAD = sub () { $val }; } else { *$AUTOLOAD = sub { $val }; } }
I'm running perl v5.6.0 on Tru64 UNIX V5.1. So $] == 5.006. Thus, the first line (with parens after "sub") is used.

If I edit dumpsys.pm and force it to use the second line (without parens), I don't get the warning. However, I'd rather not do that because (1) dumpsys.pm is a generated file, and (2) it's probably that way for a reason, right?

Your assistance in understanding and possibly fixing this warning message is appreciated. Thanks.

Replies are listed 'Best First'.
Re: "Prototype mismatch" using h2xs-generated code
by samtregar (Abbot) on Apr 26, 2002 at 18:03 UTC
    Have you tried using 5.6.1? If I remember correctly there was a fair amount of work on prototypes and h2xs between 5.6.0 and 5.6.1. If that doesn't work, try bleadperl (see perlhack for details). If you can reproduce it there then you've got something worthy of perlbug.

    -sam

      I upgraded to Perl 5.6.1, but that didn't solve anything. I guess it's off to try bleadperl...
        Did you compile with 64-bit ints? That's just as important as trying a new version.

        -sam

      Still there with bleadperl. <sigh> ... I guess it's perlbug time for me.