New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: