Eric Roode wrote:
>
> Allow me to throw another log on the fire:
>
> my $x;
> if (something)
> {
> $x = 1;
> }
> my $y = $x;
>
> This would give a compile-time warning under your RFC, warning the
> user of a possibly uninitialized $x. Okay. Next:
Yes.
> my $x;
Allow me to throw another log on the fire:
my $x;
if (something)
{
$x = 1;
}
my $y = $x;
This would give a compile-time warning under your RFC, warning the
user of a possibly uninitialized $x. Okay. Next:
my $x;
if (something)
{
$x = 1;
}
Dave Storrs wrote:
>
> On Wed, 20 Sep 2000, Eric Roode wrote:
>
> > foo();
> > print $x;
> >
> > Generate a warning, or not? Which one? Remember, foo() may initialize $x.
>
> My suggest (FWIW) would be that, if there is no execution path
> which leads to $x being defined in the
Daniel Chetlin wrote:
>
> On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> > % perl -le '$x = 3; eval "\$x++"'
> > (no warning issued)
>
> [~] $ perl -wle'$x = 3; eval "\$x++"'
> Name "main::x" used only once: possible typo at -e line 1.
Doh! Thanks.
On Wed, 20 Sep 2000, Eric Roode wrote:
> foo();
> print $x;
>
> Generate a warning, or not? Which one? Remember, foo() may initialize $x.
My suggest (FWIW) would be that, if there is no execution path
which leads to $x being defined in the second line, then a "Use of
uninit'
On Wed, 20 Sep 2000, Steve Fink wrote:
> 1 my ($x, $y, $z);
> 2 $z = 1;
> 3 my $logfile = "/tmp/log";
> 4 $x = 1 if cond();
> 5 print $x+$y;
> 6 undef $z;
> 7 print $z;
>
> --> use of uninitialized variable $y in line 5 (compile time)
> --> possible use of uninitialized variable $x in line 5 (
On Wed, 20 Sep 2000 12:30:26 -0600, Tom Christiansen wrote:
>$a = undef;
>
>You have initialized it to undef.
>Solution:
>
>Remove all references from the language to defined and undef.
Quite the reverse.
Simply assume that uninitialized variables in Perl simply don't exist,
that all v
On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> Tom Christiansen wrote:
> > Steve Fink wrote:
> > >% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
> > >Name "main::x" used only once: possible typo at -e line 1.
> >
> > Non sequitur. And no, I don't have time.
>
> It is relevant in that
Have a nice day. And thanks for all the fish.
Tom Christiansen wrote:
>
> >Tom Christiansen wrote:
> >>
> >> >Anything else? Any opinion on whether eval "" should do what it does
> >> >now, and be invisible for the purposes of this analysis; or if it should
> >> >be assumed to instead both use and initialize all visible variables? The
> >> >
>Tom Christiansen wrote:
>>
>> >Anything else? Any opinion on whether eval "" should do what it does
>> >now, and be invisible for the purposes of this analysis; or if it should
>> >be assumed to instead both use and initialize all visible variables? The
>> >former produces more spurious warnings
Tom Christiansen wrote:
>
> >Anything else? Any opinion on whether eval "" should do what it does
> >now, and be invisible for the purposes of this analysis; or if it should
> >be assumed to instead both use and initialize all visible variables? The
> >former produces more spurious warnings, the
Tom Christiansen wrote:
>
> >Same thing. If $x is lexical, it gives a definite warning. If $x is a
> >global, it says nothing. You're right; I need to point this out in the
> >RFC.
>
> Careful:
>
> sub ouch {
> my $x;
> my $fn = sub { $x++ };
> register($fn);
>
>Anything else? Any opinion on whether eval "" should do what it does
>now, and be invisible for the purposes of this analysis; or if it should
>be assumed to instead both use and initialize all visible variables? The
>former produces more spurious warnings, the latter misses many errors.
You hav
Tom Christiansen wrote:
>
> And what about $$x?
>
> Dang, are we back to this incredible confusion about what it is to be
> defined in Perl.?
>
> undef $a;
>
> That is now UNINITIALIZED. So is this:
>
> $a = undef;
>
> You have initialized it to undef. There is no reasonable differ
>But that doesn't even matter that much here; I'm saying that if the
>compiler can definitely determine that you are using an uninitialized
>variable, it should warn.
...
>$x is a global. The compiler cannot detect all possible assignments to
>or accesses of globals, so it never warns about the
Eric Roode wrote:
>
> Steve Fink wrote:
> >I am merely suggesting that the compiler detect, when it can, that
> >you're trying to use the value of a variable without ever having
> >assigned a value to that variable. And in THAT message, you had better
> >know the name of the variable, since it's
Steve Fink wrote:
>I am merely suggesting that the compiler detect, when it can, that
>you're trying to use the value of a variable without ever having
>assigned a value to that variable. And in THAT message, you had better
>know the name of the variable, since it's the basis of the analysis. And
And what about $$x?
Dang, are we back to this incredible confusion about what it is to be
defined in Perl.?
undef $a;
That is now UNINITIALIZED. So is this:
$a = undef;
You have initialized it to undef. There is no reasonable difference.
Solution:
Remove all references from th
Tom Christiansen wrote:
>
> >The warning for the use of an unassigned variable should be "use of
> >uninitialized variable C<$x>".
>
> The problem with that idea, now as before, is that this check happens
> where Perl is looking at a value, not a variable. Even were it possible
> to arduously m
>The warning for the use of an unassigned variable should be "use of
>uninitialized variable C<$x>".
The problem with that idea, now as before, is that this check happens
where Perl is looking at a value, not a variable. Even were it possible
to arduously modify Perl to handle explicitly named
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 12
Version: 2
Status: Deve
22 matches
Mail list logo
