Here's my (fixed!) code:
+208 chomp ($fsmount);
+209 $fsmount .= ' ';
+210
+211 print "*** fsmount = \"$fsmount\"";
+212 print ", empty" if $fsmount eq "";
+213 print ", undef" unless defined($fsmount);
+214 print " ***\n";
+215
+216 # if ( $fsmount =~ m=^/= ) {
+217 # $fsmount =~ s/:.*$//;
+218 my $firstchar = substr($fsmount,0,1);
+219 if ( $firstchar eq '/' ) {
+220 $fsmount =~ s/:.*//;
When I run this code with '-w', here's what I see:
# perl unix_replica.pl
*** fsmount = " " ***
Use of uninitialized value in pattern match (m//) at unix_replica.pl
line 218.
*** fsmount = "/: " ***
*** fsmount = " dev = /dev/hd4 " ***
Use of uninitialized value in pattern match (m//) at unix_replica.pl
line 218.
*** fsmount = " vol = "root" " ***
Use of uninitialized value in pattern match (m//) at unix_replica.pl
line 218.
Line 209 guarantees that there's at least one character in $fsmount,
so the 'substr($fsmount,0,1)' should always return one character
string. Everything works just fine without the '-w' option. Any ideas?
> Here's my (fixed!) code:
> +208 chomp ($fsmount);
> +209 $fsmount .= ' ';
> +210
> +211 print "*** fsmount = \"$fsmount\"";
> +212 print ", empty" if $fsmount eq "";
> +213 print ", undef" unless defined($fsmount);
> +214 print " ***\n";
> +215
> +216 # if ( $fsmount =~ m=^/= ) {
> +217 # $fsmount =~ s/:.*$//;
> +218 my $firstchar = substr($fsmount,0,1);
> +219 if ( $firstchar eq '/' ) {
> +220 $fsmount =~ s/:.*//;
> When I run this code with '-w', here's what I see:
> # perl unix_replica.pl
> *** fsmount = " " ***
> Use of uninitialized value in pattern match (m//) at unix_replica.pl
> line 218.
That's weird because line 218 is `my $firstchar = substr($fsmount,0,1)'.
In fact, I don't see any m// in your code (except for the comment in
line 216).
Your code and your error messages don't agree.
HTH, Lukas
--
There is no .
I think there's something you aren't telling us. :-) I don't see a
pattern match on line 218. If the substr were the location of the
error, I'd expect a different message:
$ perl -we 'my $f = substr(undef,0,1)'
Use of uninitialized value in substr at -e line 1.
None of the (uncommented) code above seems to be a pattern match, so I
think the line numbering must be off. Maybe you could post a
self-contained script (sans line numbers) that exhibits the problem?
Jon
> Sam Denton schrob:
>> +218 my $firstchar = substr($fsmount,0,1);
>> Use of uninitialized value in pattern match (m//) at unix_replica.pl
>> line 218.
>
> That's weird because line 218 is `my $firstchar = substr($fsmount,0,1)'.
> In fact, I don't see any m// in your code (except for the comment in
> line 216).
If Sam is using an old version of Perl, *and* uses elsif, the line number
(s) reported can be wrong.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Yes, I noticed that as well. Originally, my code only had lines 208,
216-217, and 220; the other lines are debugging code that I've added
trying to track things down. The message has always been the same
except for the line number, which has always pointed to whichever came
first of the "if" statement or the call to "substr". The message has
always said "pattern match" and I think that its always said "(m/)",
regardless of the way I coded the regex.
I suspect that the (m//) is a generic message for any pattern match; I
further wonder if, internally, the substr is getting translated into a
pattern match. The Perl optimizer does some strange things sometimes.
I posted the original question about two minutes before leaving work
today (my wife had to get our daughter to girl scouts), but I can
double-check things tomorrow. I'll also try shrinking the code down to
the minimum that exhibits the problem.
> OK, my first post had a bug, but it's a real problem, honest.
Post a short and complete program *that we can run* that
makes those warnings, and we will help you make the warnings
go away.
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas
Ok this is the problem. Line 212. Look at the following complete code.
# At this point $fsmount is undefined
print "*** fsmount = \"$fsmount\"";
print ", empty" if $fsmount eq "";
print ", undef" unless defined($fsmount);
print " ***\n";
# Now we switch the order of the tests
print "*** fsmount = \"$fsmount\"";
print ", undef" unless defined($fsmount);
print ", empty" if $fsmount eq "";
print " ***\n";
Now we run it.
*** fsmount = "", empty, undef ***
*** fsmount = "", undef, empty ***
So undef is the same as "". In effect the test coerced the undef into an empty
string.
Reorder your tests.
>OK, my first post had a bug, but it's a real problem, honest.
[snip]
>string. Everything works just fine without the '-w' option. Any ideas?
Well, when I read your post yesterday I was too tired to read your
actual code, even if you had been sensible enough to quote only the
relevant lines. Taking this into account I answered the way I did, but
when I noticed the error you were doing, as pointed out by many people
here, I regretted having done so. However that *may* still apply,
though I *recommend* you do that only if you're sure you're not doing
another mistake like the previous one.
If the warning is really "spurious", i.e. you *do* know why you're
getting it, but do not want to hear it anyway, then as I already
suggested, just locally disable 'uninitialized' warnings.
HTH,
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
Lines 205-215 were inserted while trying to figure out why I was getting
the error message; I left them in because they were supposed to show
that the variable *wasn't* uninitialized. Unfortunately, one of the
lines introduced a different mistake that I caught a few seconds after
posting. My second posting was an attempt to correct the error, but I
notice that the first post is still getting responces. For these errors
that waste the time of people who are attempting to assist me, I most
sincerely apologize.
> If the warning is really "spurious", i.e. you *do* know why you're
> getting it, but do not want to hear it anyway, then as I already
> suggested, just locally disable 'uninitialized' warnings.
spurious \SPYUR-ee-uhs\, adjective:
1. Not proceeding from the true or claimed source; not genuine; false.
I call the message "spurious" because it claims that there's an
uninitialized variable being used in a given statement, but I am unable
to find one. That usually indicates a failure on my part, but in this
case I also am using 'use strict;' and it, too, fails to find anything
wrong when the '-w' option is removed. Either there's a very subtl
problem elsewhere and the message is pointing to the wrong place (in
which case the first clause of the definition holds), or the message is
a lie (in which case the last clause holds).
As I previously posted, I will try to reduce the program to something
smaller that reproduces the error. This might take a while because the
program is parsing AIX-specific files and removing the system
dependencies could be, hmmm, fun.
> As I previously posted, I will try to reduce the program to something
> smaller that reproduces the error. This might take a while because the
> program is parsing AIX-specific files and removing the system
> dependencies could be, hmmm, fun.
There is a high probability that the problem will reveal itself
to you as you go through the exercise described above.
Which is why the Posting Guidelines suggest such an exercise. :-)
>to find one. That usually indicates a failure on my part, but in this
>case I also am using 'use strict;' and it, too, fails to find anything
>wrong when the '-w' option is removed. Either there's a very subtl
As a side note C<use strict;> and C<use warnings;> are to a large
extent orthogonal. Hence your claim doesn't make *much* sense...
To be fair, a common source of 'use of uninit value' warnings is
misspelling variable names when not using strict, so the OP is simply
saying that he has eliminated that possible source of error.
Ben
--
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
/Alcestis/) [ flame, and falls out of sight. ] b...@morrow.me.uk