Uninitialized value $ExtUtils::ParseXS::num in subtraction #12085
Comments
From perl@cjmweb.netThis is a bug report for perl from perl@cjmweb.net, I'm working on a Perl module using XS to bind to a C library. When I Use of uninitialized value $num in subtraction (-) at This is triggered by the code generated by ExtUtils::Constant. I'm using ExtUtils::Constant 0.23, ExtUtils::ParseXS 3.15, I've managed to pare it down to a reasonably small test case that To reproduce the bug, clone the repo, type "perl Build.PL" and then $ perl Build.PL You'll only see "Regenerating constants..." if you have Whatever the problem is, it doesn't seem to stop the code from I've asked about this on http://stackoverflow.com/q/10378986/8355 Flags: Site configuration information for perl 5.14.2: Configured by Gentoo at Sat Oct 22 18:25:36 CDT 2011. Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: Locally applied patches: @INC for perl 5.14.2: Environment for perl 5.14.2: PATH=/home/cjm/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/games/bin:/var/qmail/bin |
From @jkeenanOn Sat May 05 12:37:25 2012, cjm wrote:
Do you get this warning if you use the (older) version of jimk |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Sat May 05 15:15:09 2012, jkeenan wrote:
I answered my own question: Yes. ##### In the version you are using, 3.15, modify line 1117 of 1117 $self->{var_num} = $self->{args_match}->{$var_name}; to: $self->{var_num} = ($self->{args_match}->{$var_name}) || 0; That should eliminate the uninitialized value warning. However, I Thank you very much. |
From perl@cjmweb.netOn Sat May 05 15:38:10 2012, jkeenan wrote:
That won't do much good for me, since the people installing my module I guess I'll just have to include a note about it in the README. |
From @jkeenanOn Sat May 05 16:05:47 2012, cjm wrote:
I was only asking you to do that for our diagnostic purposes. Your If I import Data::Dumper into ParseXS.pm and modify ExtUtils::ParseXS ##### ... then try to build your module, I get this output: ##### So the second time through a loop, there is a difference between the key However, I don't know/remember enough of ParseXS to say what that means. Thank you very much. |
From perl@cjmweb.netOn Sat May 05 17:56:48 2012, jkeenan wrote:
Sorry, I misunderstood. Yes, adding "|| 0" to that line removes the |
From @jkeenanPlease review the patch attached. Thank you very much. |
From @jkeenan0001-Diagnosis-of-uninitialized-value-warning-reported-by.patchFrom f8c3bbd4e2315ec1599f7dc346dd1c00836479bf Mon Sep 17 00:00:00 2001
From: jkeenan <jkeenan@cpan.org>
Date: Sat, 5 May 2012 23:31:52 -0400
Subject: [PATCH] Diagnosis of uninitialized value warning reported by Christopher J. Madsen++.
The set of keys found in the hash $self->{args_found} fundamentally derives
from the parsing of $func_header inside process_file(). The members of that
set are fixed by the time INPUT_handler() is called for the first time within
that subroutine. They therefore do not necessarily include every instance of
$var_name; that variable only exists within INPUT_handler().
$self->{args_match}->{$var_name} does not necessarily exist. So, in order to
be able to use $self->{var_num} in arithmetic expressions, we have to provide
it with a defined default value of 0.
For RT #112776.
---
dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm b/dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
index 883d905..19c46c0 100644
--- a/dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
+++ b/dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
@@ -1114,7 +1114,7 @@ sub INPUT_handler {
print "\t" . map_type($self, $var_type, undef);
$printed_name = 0;
}
- $self->{var_num} = $self->{args_match}->{$var_name};
+ $self->{var_num} = $self->{args_match}->{$var_name} || 0;
if ($self->{var_num}) {
my $typemap = $self->{typemap}->get_typemap(ctype => $var_type);
--
1.6.3.2
|
From perl@cjmweb.netOn Sat May 05 20:53:41 2012, jkeenan wrote:
Well, I can confirm that it solves my problem, but I don't know enough |
From @tseeOn 05/06/2012 05:58 AM, Christopher J. Madsen via RT wrote:
That is precisely why I hadn't included a simple change like the I'm on the fence on whether it's better to apply the patch to avoid --Steffen |
From @nwc10On Tue, May 08, 2012 at 07:47:48AM +0200, Steffen Mueller wrote:
I fear that it's plaster, and hence applying it does nothing to solve the Nicholas Clark |
From @tonycozOn Tue, May 08, 2012 at 10:13:58AM +0100, Nicholas Clark wrote:
There's one or both of two problems here: a) the generated Build forces $^W on, which isn't the normal state b) the undefined value itself is caused because the: const char * s = SvPV(sv, len); in const-xs.inc is for a name that isn't a parameter. I can produce the same warning with code like: #include "EXTERN.h" #include "ppport.h" MODULE = Foo PACKAGE = Foo PREFIX = LIBMTP_ PROTOTYPES: DISABLE void I suspect the better change would be to change: my $arg = "ST(" . ($num - 1) . ")"; to something along the lines of: my $arg = $num ? "ST(" . ($num - 1) . ")" Tony |
From @cpansproutOn Tue May 08 06:34:12 2012, tonyc wrote:
Just a reminder. :-) -- Father Chrysostomos |
From @tonycozOn Tue Jun 19 21:58:01 2012, sprout wrote:
Tony |
|
@tonycoz - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#112776 (status was 'resolved')
Searchable as RT112776$
The text was updated successfully, but these errors were encountered: