[32329] in Perl-Users-Digest
Perl-Users Digest, Issue: 3596 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 20 14:09:33 2012
Date: Fri, 20 Jan 2012 11:09:15 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 20 Jan 2012 Volume: 11 Number: 3596
Today's topics:
Re: lib::libXML parsing comments (Fergus McMenemie)
Re: lib::libXML parsing comments (Seymour J.)
perl syntax check <hhr-m@web.de>
Re: perl syntax check <ben@morrow.me.uk>
Re: perl syntax check (Tim McDaniel)
Re: perl syntax check <ben@morrow.me.uk>
Re: perl syntax check <hhr-m@web.de>
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? <kaz@kylheku.com>
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? (Seymour J.)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 20 Jan 2012 03:50:48 +0000
From: fergus@twig-me-uk.not.here (Fergus McMenemie)
Subject: Re: lib::libXML parsing comments
Message-Id: <1ke5gyg.fx0dum17mwivcN%fergus@twig-me-uk.not.here>
Hummm, I had cancelled this message but I guess either cancelling did
not work or I was not quick enough. However everything works fine. I
had not properly accounted for how the comment was nested within my
documents structure.
Sorry for wasting your time. But on the other hand your example is
lovely.
en Morrow <ben@morrow.me.uk> wrote:
> Quoth fergus@twig-me-uk.not.here (Fergus McMenemie):
> >
> > I have to parse an XML document and rewrite it, after sorting some of
> > the nodes. Some of these nodes have assocated comments which I have been
> > told have to remain beside their node.
> >
> > However walking the list of nodes returned by XML::LibXML's
> > getChildNodes or childNodes I never see XML_COMMENT_NODE returned. It
> > looks as though the parser is discarding comments.
>
> Works for me:
>
> #!/opt/perl/bin/perl
>
> use 5.010;
> use warnings;
> use strict;
> use XML::LibXML;
>
> my $X = XML::LibXML->load_xml(IO => \*DATA);
> say sprintf "[%s] [%s]", $_->nodeName, $_->textContent
> for $X->documentElement->childNodes;
>
> __END__
> <?xml version="1.0"?>
>
> <xml>
> <!-- comment -->
> <element/>
> </xml>
>
> gives
>
> [#text] [
> ]
> [#comment] [ comment ]
> [#text] [
> ]
> [element] []
> [#text] [
> ]
>
> Can you post a miminal example which doesn't do what you want?
>
> Ben
------------------------------
Date: Fri, 20 Jan 2012 11:10:47 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: lib::libXML parsing comments
Message-Id: <4f199207$14$fuzhry+tra$mr2ice@news.patriot.net>
In <1ke5gyg.fx0dum17mwivcN%fergus@twig-me-uk.not.here>, on 01/20/2012
at 03:50 AM, fergus@twig-me-uk.not.here (Fergus McMenemie) said:
>Hummm, I had cancelled this message but I guess either cancelling
>did not work
Due to rogue cancels, the big players mo l;onger honor cancels from
the general public.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 20 Jan 2012 17:03:42 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: perl syntax check
Message-Id: <alpine.LNX.2.00.1201201654490.5288@lxhri01.ws.lrz.de>
I'd like to do a perl syntax check as distinct from an execution. I am
well aware that there are many errors that cannot be found without
execution but I'd like to first remove the errors that can be found
without execution and *then* execute the script. My attempt was using the
-wc flag, but this has no effect whatsoever.
> perl -wc ali.pl
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 362.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 363.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 365.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 419.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 432.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
Status: 500
Content-type: text/html
<h1>Software error:</h1>
. . .
The script is intended as CGI Script. The format of the error messages, to
wit the same format as web server log entries and a status code 500, is
hardly conceivable as pure syntax error messages from perl. Rather, the
code must have been executed somehow. How could I prevent that?
--
Helmut Richter
------------------------------
Date: Fri, 20 Jan 2012 16:58:27 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perl syntax check
Message-Id: <j2jou8-qpi.ln1@anubis.morrow.me.uk>
Quoth Helmut Richter <hhr-m@web.de>:
> I'd like to do a perl syntax check as distinct from an execution. I am
> well aware that there are many errors that cannot be found without
> execution but I'd like to first remove the errors that can be found
> without execution and *then* execute the script. My attempt was using the
> -wc flag, but this has no effect whatsoever.
It does. -c makes perl stop at the end of the main compile-time phase,
exactly at the point where it stops invoking CHECK blocks and starts
invoking INIT blocks.
> > perl -wc ali.pl
> [Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
> ali.pl line 362.
> [Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
<snip>
> Status: 500
> Content-type: text/html
<snip>
>
> The script is intended as CGI Script. The format of the error messages, to
> wit the same format as web server log entries and a status code 500, is
> hardly conceivable as pure syntax error messages from perl. Rather, the
> code must have been executed somehow. How could I prevent that?
'use' statements happen at compile time. (That's the point.) This means
that any code executed as part of a module's ->import method will be run
even under -c. Presumably you are using some module (CGI::Carp?) that
hooks into $SIG{__WARN__} (or something similar) and changes the warning
format: the only way to stop that code from running is to comment out
the 'use' statement.
As a matter of good style, modules shouldn't do anything 'important'
(open files, connect to databases, print output...) during compile time,
but should wait to be asked. Since this *is* just a matter of style,
though, there is nothing preventing modules from ignoring it if they
choose to. CGI::Carp is slightly bending the rules in the interest of
making debugging possible for people with no shell access.
As for preventing it: you can't. For one thing, 'strict' and 'warnings'
are switched on by explicit code in their ->import methods; if you could
somehow prevent execution of any Perl at all you would find strictures
were never switched on. For another, your code probably wouldn't even
compile, since it probably needs subs imported at compile time: and an
->import method can do anything it likes, you can't restrict it to just
exporting symbols and nothing else.
That said, you may be interested in Perl::Critic, which performs static
linting of Perl code (without executing anything ever). Personally I
find it inflexible and irritating (I won't use a spell-checker, either),
but a lot of people seem to find it useful. It's based on Adam Kennedy's
PPI, which spends a long time explaining exactly why it's impossible to
parse Perl statically and then goes on to make a best-effort attempt
anyway.
Ben
------------------------------
Date: Fri, 20 Jan 2012 17:41:27 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: perl syntax check
Message-Id: <jfc907$drf$1@reader1.panix.com>
In article <j2jou8-qpi.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Helmut Richter <hhr-m@web.de>:
>> I'd like to do a perl syntax check as distinct from an execution. I
>> am well aware that there are many errors that cannot be found
>> without execution but I'd like to first remove the errors that can
>> be found without execution and *then* execute the script. My
>> attempt was using the -wc flag, but this has no effect whatsoever.
>
>It does. -c makes perl stop at the end of the main compile-time
>phase, exactly at the point where it stops invoking CHECK blocks and
>starts invoking INIT blocks.
>
>> > perl -wc ali.pl
>> [Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
>> ali.pl line 362.
>> [Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
>> Status: 500
>> Content-type: text/html
>>
>> <h1>Software error:</h1>
>> . . .
>>
>> The script is intended as CGI Script. The format of the error
>> messages, to wit the same format as web server log entries and a
>> status code 500, is hardly conceivable as pure syntax error
>> messages from perl. Rather, the code must have been executed
>> somehow. How could I prevent that?
>
>'use' statements happen at compile time. (That's the point.) This
>means that any code executed as part of a module's ->import method
>will be run even under -c. Presumably you are using some module
>(CGI::Carp?) that hooks into $SIG{__WARN__} (or something similar)
>and changes the warning format: the only way to stop that code from
>running is to comment out the 'use' statement.
I don't think the major problem is the log line format. His problem
statement is not so clear, but I think the problem is in the lines you
trimmed some of and that I restored above:
Status: 500
Content-type: text/html
<h1>Software error:</h1>
. . .
That appears to be running the actual code, despite (as your write)
>As a matter of good style, modules shouldn't do anything 'important'
>(open files, connect to databases, print output...) during compile
>time, but should wait to be asked. Since this *is* just a matter of
>style, though, there is nothing preventing modules from ignoring it
>if they choose to.
Just to be sure: Helmut, how is the CGI output being generated?
Surely it isn't
BEGIN {
print standard_HTTP_header();
print "<html>\n<head>\n"; ...
}
... or is it?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 20 Jan 2012 18:31:07 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perl syntax check
Message-Id: <bgoou8-grj.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <j2jou8-qpi.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >'use' statements happen at compile time. (That's the point.) This
> >means that any code executed as part of a module's ->import method
> >will be run even under -c. Presumably you are using some module
> >(CGI::Carp?) that hooks into $SIG{__WARN__} (or something similar)
> >and changes the warning format: the only way to stop that code from
> >running is to comment out the 'use' statement.
>
> I don't think the major problem is the log line format. His problem
> statement is not so clear, but I think the problem is in the lines you
> trimmed some of and that I restored above:
>
> Status: 500
> Content-type: text/html
>
> <h1>Software error:</h1>
> . . .
>
> That appears to be running the actual code, despite (as your write)
Assuming this is CGI::Carp, that output is almost certainly coming from
the __DIE__ handler. This is running because perl is dieing at compile
time, due to there being a fatal compile-time error (probably a syntax
error) somewhere in the code. If the code were correct it would stop
without producing any output.
Ben
------------------------------
Date: Fri, 20 Jan 2012 19:46:55 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: perl syntax check
Message-Id: <alpine.LNX.2.00.1201201941050.5288@lxhri01.ws.lrz.de>
On Fri, 20 Jan 2012, Ben Morrow wrote:
> Assuming this is CGI::Carp, that output is almost certainly coming from
> the __DIE__ handler. This is running because perl is dieing at compile
> time, due to there being a fatal compile-time error (probably a syntax
> error) somewhere in the code. If the code were correct it would stop
> without producing any output.
Yes, it is certainly from "use CGI::Carp qw(fatalsToBrowser);" which I use
while debugging -- later without the fatalsToBrowser. It works fine for
errors at run time but not at compile time. It would be nice it did, just
sending the syntax errors to the browser screen, but it doesn't: the
browser gets an error 500 and the syntax errors go to the Nirwana.
Commenting out this line when doing syntax checks only is an acceptable
option.
Thank you.
--
Helmut Richter
------------------------------
Date: Fri, 20 Jan 2012 13:36:12 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <87d3aeebsj.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Ben Morrow <ben@morrow.me.uk> wrote:
>>I think that was Rainer's point: Perl variables are never 'undefined' in
>>the sense of the C standard, so the 'uninitialized value' warnings tend
>>to be more noise than useful. They certainly aren't equivalent to the
>>'variable used without being assigned a value' warnings C compilers are
>>so fond of, which often do indicate genuine bugs.
>
> Using a variable without it having been assigned a value may indeed
> be a genuine bug.
Using a variable after some value was assigned to it may also be a
genuine bug. It all depends on the value and how it is supposed to be
used. Everything might be an error, provided the context is unknown.
>>In perl's defence, they were much more useful back before 'my' and
>>'strict' were invented. In Perl 4 it was terribly easy to misspell a
>>variable name, and the only notice you got was (if you were lucky) an
>>'uninitialized value' warning. IMHO in Perl 5 they are redundant.
>
> Yesterday, I ran across code where $tbl{FACIlITY} was used. Luckily,
> he used cut-and-paste or autocomplete, so it was actually consistent
> in about 9 different uses! But a bad hash key is something that "use
> strict" doesn't catch.
And neither does the uninitialized warning catch that, except in the
case where the value associated with this key happens to be undef and
this happens to be wrong. Which essentially depends on the style the
code was written in, namely,
> Personally, I am a great fan of initializing variables, even to their
> defaults. I use it to indicate "I've considered what the initial
> value should be, and it should be what I indicate".
was it written by someone who believes that functionally useless code
is a better way to document metainformation about the code than
comments. And in my opinion, this is certainly not the case: Some
piece of code which can be removed without changing the meaning of the
larger code agglomerate it is part of communicates nothing beyond the
fact that somebody wrote it on its own because it is inherently
meaningless in the context it appears in. It is probable that it was
meant to be 'useful' in some way, but in absence of other information,
this 'some way' might as well have been 'meant to confuse the
uninitiated': Only the author knows and his uncommunicated thoughts
are not accessible to anyone else. And there's another downside to
that: It makes the 'executable text' more complicated and thus, more
difficult to understand. So, if you want to annotate your code, please
comment it and don't obfuscate it with exectuable annotations.
[...]
> my $max = undef;
> foreach (@values) {
> $max = $_ if ! defined $max || $max < $_;
> }
While this is also a nice example of a case where a property of
undef is useful in code (namely, that undef converted to a numerical
value yields 0), the sensible way to express this would be (sensible
from a theoretical point of view, also untested)
$max = $values[0];
for (1 .. $#values) {
$max = $values[$_] if $values[$_] > $max;
}
or
$max = $values[0]
$values[$_] > $max and $max = $values[$_] for (1 .. $#values);
which initializes the variable to a sensible start value, thereby
avoiding the meaningless assignment, the 'uninitialized value' warning
and the repeated !defined test which will be true on the first
iteration and false on all subsequent ones. perl still doesn't do
invariant code motion (AFAIK) ...
------------------------------
Date: Fri, 20 Jan 2012 11:07:31 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f199143$13$fuzhry+tra$mr2ice@news.patriot.net>
In <9vjmu8-5m3.ln1@anubis.morrow.me.uk>, on 01/19/2012
at 11:01 PM, Ben Morrow <ben@morrow.me.uk> said:
>you get '456' the first time only.
>If you write
> for (1..2) {
> my @arglist;
> BEGIN { @arglist = 4, 5, 6 }
> say $_, @arglist;
> }
[h:\]perl -wle 'for (1..2) { my @arglist; BEGIN { @arglist = 4, 5, 6
} say $_, @arglist; }'
Useless use of private array in void context at -e line 1.
Can't call method "say" without a package or object reference at -e
line 1.
[h:\]perl -wle 'for (1..2) { my @arglist; BEGIN { @arglist = 4, 5, 6
} print $_, @arglist, "\n"; }'
14
2
Now *that* is surprising!
>you get '456' the first time only.
I just get 4, which I don't understand.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 20 Jan 2012 10:52:47 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f198dcf$12$fuzhry+tra$mr2ice@news.patriot.net>
In <cojmu8-5m3.ln1@anubis.morrow.me.uk>, on 01/19/2012
at 10:57 PM, Ben Morrow <ben@morrow.me.uk> said:
>I think that was Rainer's point: Perl variables are never 'undefined'
>in the sense of the C standard, so the 'uninitialized value' warnings
>tend to be more noise than useful.
Which is why I'd like to eliminate them if it doesn't make my code
awkward. E.g., I'm willing to add // '' after an expression, but I'm
not willing to break a quoted string containing multiple variable
names into pieces just so that I can add // '' after each name.
>IMHO in Perl 5 they are redundant.
I've had cases where the 'uninitialized value' warnings helped me to
find a bug.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 20 Jan 2012 17:05:59 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <ngjou8-qpi.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <9vjmu8-5m3.ln1@anubis.morrow.me.uk>, on 01/19/2012
> at 11:01 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >you get '456' the first time only.
>
> >If you write
> > for (1..2) {
> > my @arglist;
> > BEGIN { @arglist = 4, 5, 6 }
> > say $_, @arglist;
> > }
>
> [h:\]perl -wle 'for (1..2) { my @arglist; BEGIN { @arglist = 4, 5, 6
> } say $_, @arglist; }'
> Useless use of private array in void context at -e line 1.
> Can't call method "say" without a package or object reference at -e
> line 1.
Anything I post should be assumed to be under 'use 5.010;' or -E.
> [h:\]perl -wle 'for (1..2) { my @arglist; BEGIN { @arglist = 4, 5, 6
> } print $_, @arglist, "\n"; }'
> 14
>
> 2
>
> Now *that* is surprising!
No, I'm just stupid :).
> >you get '456' the first time only.
>
> I just get 4, which I don't understand.
It parses as
BEGIN { (@arglist = 4), 5, 6 }
I should have written
BEGIN { @arglist = (4, 5, 6) }
Ben
------------------------------
Date: Fri, 20 Jan 2012 17:36:30 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: When is @_ undefined?
Message-Id: <20120120092140.220@kylheku.com>
On 2012-01-20, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> tmcd@panix.com (Tim McDaniel) writes:
>> Ben Morrow <ben@morrow.me.uk> wrote:
>>>I think that was Rainer's point: Perl variables are never 'undefined' in
>>>the sense of the C standard, so the 'uninitialized value' warnings tend
>>>to be more noise than useful. They certainly aren't equivalent to the
>>>'variable used without being assigned a value' warnings C compilers are
>>>so fond of, which often do indicate genuine bugs.
>>
>> Using a variable without it having been assigned a value may indeed
>> be a genuine bug.
>
> Using a variable after some value was assigned to it may also be a
> genuine bug.
>
> It all depends on the value and how it is supposed to be
> used. Everything might be an error, provided the context is unknown.
Uses of uninitialized variables are erroneous regardless of context.
------------------------------
Date: Fri, 20 Jan 2012 18:09:37 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <874nvqxn32.fsf@sapphire.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2012-01-20, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> tmcd@panix.com (Tim McDaniel) writes:
>>> Ben Morrow <ben@morrow.me.uk> wrote:
>>>>I think that was Rainer's point: Perl variables are never 'undefined' in
>>>>the sense of the C standard, so the 'uninitialized value' warnings tend
>>>>to be more noise than useful. They certainly aren't equivalent to the
>>>>'variable used without being assigned a value' warnings C compilers are
>>>>so fond of, which often do indicate genuine bugs.
>>>
>>> Using a variable without it having been assigned a value may indeed
>>> be a genuine bug.
>>
>> Using a variable after some value was assigned to it may also be a
>> genuine bug.
>>
>> It all depends on the value and how it is supposed to be
>> used. Everything might be an error, provided the context is unknown.
>
> Uses of uninitialized variables are erroneous regardless of context.
There is no such thing as 'an uninitialized variable' in Perl: The
initial value of a scalar variable is the so-called 'undefined value':
When being used as a string, it is equivalent to an empty string and
when being used as a number, it will have the numerical value
0. That's actually even reflected in the code which generates these
warnings because it doesn't generate them for some operations the
people who wrote considered to be to commonly useful to warn about.
Eg, this will generate a warning:
perl -w -e 'my ($a, $b); $b = $a . "t";'
but this won't:
perl -w -e 'my $a; $a = $a . "t";'
(at least for perl 5.10.1).
------------------------------
Date: Fri, 20 Jan 2012 18:32:24 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <oioou8-grj.ln1@anubis.morrow.me.uk>
Quoth Kaz Kylheku <kaz@kylheku.com>:
> On 2012-01-20, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> > tmcd@panix.com (Tim McDaniel) writes:
> >> Ben Morrow <ben@morrow.me.uk> wrote:
> >>>I think that was Rainer's point: Perl variables are never 'undefined' in
> >>>the sense of the C standard, so the 'uninitialized value' warnings tend
> >>>to be more noise than useful. They certainly aren't equivalent to the
> >>>'variable used without being assigned a value' warnings C compilers are
> >>>so fond of, which often do indicate genuine bugs.
> >>
> >> Using a variable without it having been assigned a value may indeed
> >> be a genuine bug.
> >
> > Using a variable after some value was assigned to it may also be a
> > genuine bug.
> >
> > It all depends on the value and how it is supposed to be
> > used. Everything might be an error, provided the context is unknown.
>
> Uses of uninitialized variables are erroneous regardless of context.
In Perl or in C? In C you are correct, in Perl you are incorrect.
Ben
------------------------------
Date: Fri, 20 Jan 2012 14:01:12 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f19b9f8$19$fuzhry+tra$mr2ice@news.patriot.net>
In <ngjou8-qpi.ln1@anubis.morrow.me.uk>, on 01/20/2012
at 05:05 PM, Ben Morrow <ben@morrow.me.uk> said:
>Anything I post should be assumed to be under 'use 5.010;' or -E.
Well, while I'm currently using 5.10.0, there are people stuck with
5.8[1].
>I should have written
> BEGIN { @arglist = (4, 5, 6) }
Ah! As I tell my children, it's not magic once you understand how it
works. Thanks.
[1] Stuck with ear;ier versions? I'm not sure that I'm strong
enough for the answer.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3596
***************************************
