my $var = val if (..) doesn't work properly #3548

p5pRT · 2001-03-09T16:31:09Z

Migrated from rt.perl.org#6003 (status was 'resolved')

Searchable as RT6003$

p5pRT · 2001-03-09T16:31:09Z

From madison@transmeta.com

If a variable is declared "my" and then conditional set with
a trailing if, the value is *not* undefined if the condition isn't
met. Here's some example code:

-------------------------
sub joe {
# These should arguably be the same:
#my $x; $x = 42 if (0);
my $x = 42 if (0);

print "x: $x\n";
$x = 1001; # This setting should be lost
}

joe();
joe();
-------------------------

The first line declares the variable and then conditionally either sets
the variable or leaves it as undef.
The second line declares the variable, and conditionally either sets
the variable or leaves it as junk (most likely the previous my value)

You could argue that the "my" becomes part of the condition, so if
the condition is false, then the variable isn't scoped as a my variable,
but if that was the case the script should get an error from "use strict"

Perl Info



Site configuration information for perl 5.00503:

Configured by root at Mon Aug 30 23:08:56 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.2.5-22smp, archname=i386-linux
    uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2 09:11:51 edt 1999 i686 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
    cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lc -lposix -lcrypt
    libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/lib/perl5/5.00503/i386-linux
    /usr/lib/perl5/5.00503
    /usr/lib/perl5/site_perl/5.005/i386-linux
    /usr/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/home/madison
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/madison/bin/i386-linux-libc6:/home/madison/bin:.:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/sbin:/sbin:/usr/local/sbin:/proj/hw/bin:/proj/hw/bin/i386-linux-libc6:/cad/scripts:/usr/local/contrib/bin:.:/proj/sw/astro/tools/i386-linux-libc6/bin
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

p5pRT · 2001-03-09T16:37:23Z

From @pjscott

At 04:29 PM 3/9/01 -0800, madison@transmeta.com wrote:

This is a bug report for perl from perlbug@daveola.com,
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------
[Please enter your report here]

If a variable is declared "my" and then conditional set with
a trailing if, the value is *not* undefined if the condition isn't
met. Here's some example code:

-------------------------
sub joe {
# These should arguably be the same:
#my $x; $x = 42 if (0);
my $x = 42 if (0);

print "x: $x\n";
$x = 1001; # This setting should be lost
}

joe();
joe();
-------------------------

This is well-known behavior and arguably not a bug. my() has compile-time
and run-time effects. Do a search for "Tom Christiansen" and "who says
Perl doesn't have statics?" and you may turn up a previous thread :-)

The first line declares the variable and then conditionally either sets
the variable or leaves it as undef.
The second line declares the variable, and conditionally either sets
the variable or leaves it as junk (most likely the previous my value)

You could argue that the "my" becomes part of the condition, so if
the condition is false, then the variable isn't scoped as a my variable,
but if that was the case the script should get an error from "use strict"

[Please do not change anything below this line]
-----------------------------------------------------------------

---
Site configuration information for perl 5.00503:

Configured by root at Mon Aug 30 23:08:56 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.5-22smp, archname=i386-linux
uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2
09:11:51 edt 1999 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

---
@INC for perl 5.00503:
/usr/lib/perl5/5.00503/i386-linux
/usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux
/usr/lib/perl5/site_perl/5.005
.

---
Environment for perl 5.00503:
HOME=/home/madison
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/home/madison/bin/i386-linux-libc6:/home/madison/bin:.:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/sbin:/sbin:/usr/local/sbin:/proj/hw/bin:/proj/hw/bin/i386-linux-libc6:/cad/scripts:/usr/local/contrib/bin:.:/proj/sw/astro/tools/i386-linux-libc6/bin
PERL_BADLANG (unset)
SHELL=/bin/tcsh

p5pRT · 2001-03-09T19:20:38Z

From @pjscott

At 05:18 PM 3/9/01 -0800, you wrote:

This is well-known behavior and arguably not a bug. my() has compile-time
and run-time effects. Do a search for "Tom Christiansen" and "who says
Perl doesn't have statics?" and you may turn up a previous thread :-)

I can't find such a thread - should I be searching the web or news?

If it's not a bug, then it certainly allows for buglike behavior:

--------------------------------------------------
#!/usr/bin/perl
use strict;

sub joe { my $x = 42 if (0); return \$x; }

my $y = joe();
my $z = joe();
$$y = 12;
printf "Hey: $z is $$z\n";
--------------------------------------------------

This is, of course, demonstrating that joe() now has an
unintentional static variable without using any variables
outside it's own scope. I presume this is what the Tom
Christiansen post is about - do you know where I can find it?

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00723.html
is talking about something else, to be sure, but it demonstrates that the
behavior you observed has been known about for some time. If it hasn't
been changed since then it's probably not considered a bug.

There's a thread on the topic itself at
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg00686.html

p5pRT · 2001-03-10T11:02:12Z

From [Unknown Contact. See original ticket]

Lightning flashed, thunder crashed and Peter Scott <Peter@PSDT.com> whispered:
| http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00723.html
| is talking about something else, to be sure, but it demonstrates that the
| behavior you observed has been known about for some time. If it hasn't
| been changed since then it's probably not considered a bug.

*chuckle*
Just because it is an old bug doesn't necessarily mean it isn't a bug.
There are outstanding bugs in the database dating back to early '99, which
is when I believe we first started using the nugs database. Not that I'm
saying this is a bug, or isn't a bug. Just that age has nothing to do with
bugginess.

-spp

p5pRT · 2001-03-10T11:05:07Z

From @jhi

On Sat, Mar 10, 2001 at 02:10:13PM -0500, Stephen P. Potter wrote:

Lightning flashed, thunder crashed and Peter Scott <Peter@PSDT.com> whispered:
| http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00723.html
| is talking about something else, to be sure, but it demonstrates that the
| behavior you observed has been known about for some time. If it hasn't
| been changed since then it's probably not considered a bug.

*chuckle*
Just because it is an old bug doesn't necessarily mean it isn't a bug.
There are outstanding bugs in the database dating back to early '99, which
is when I believe we first started using the nugs database. Not that I'm

There are also lots of bugs that are just open because nobody hasn't
verified them for validity with more recent Perls, or because they
are hard to duplicate.

saying this is a bug, or isn't a bug. Just that age has nothing to do with
bugginess.

-spp

p5pRT · 2001-03-10T12:03:17Z

From [Unknown Contact. See original ticket]

|
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00723.html
| is talking about something else, to be sure, but it demonstrates that
the
| behavior you observed has been known about for some time. If it
hasn't
| been changed since then it's probably not considered a bug.

*chuckle*
Just because it is an old bug doesn't necessarily mean it isn't a bug.
There are outstanding bugs in the database dating back to early '99,
which
is when I believe we first started using the nugs database. Not that
I'm

There are also lots of bugs that are just open because nobody hasn't
verified them for validity with more recent Perls, or because they
are hard to duplicate.

... and there are also a lot of bugs that even not open, because nobody even
noticed them.

Just joking.

<!ENTITY Vadim REALLIFE "St.Petersburg, Russia">
&Vadim;

p5pRT · 2001-03-10T17:32:16Z

From @pjscott

At 02:10 PM 3/10/01 -0500, Stephen P. Potter wrote:

Lightning flashed, thunder crashed and Peter Scott <Peter@PSDT.com> whispered:
| http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00723.html
| is talking about something else, to be sure, but it demonstrates that the
| behavior you observed has been known about for some time. If it hasn't
| been changed since then it's probably not considered a bug.

*chuckle*
Just because it is an old bug doesn't necessarily mean it isn't a bug.
There are outstanding bugs in the database dating back to early '99, which
is when I believe we first started using the nugs database. Not that I'm
saying this is a bug, or isn't a bug. Just that age has nothing to do with
bugginess.

Shucks, you go and spoil a perfectly good attempt to promulgate the
infallibility of the P5P :-)

Anyway, the other thread I mentioned demonstrated that at the very least
there's insufficient agreement that this behavior constitutes a bug.

p5pRT · 2001-03-12T16:36:09Z

From [Unknown Contact. See original ticket]

There's a thread on the topic itself at
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg00686.html

Fine enough, but then I claim that this is a bug:

use strict;

sub fu {
my $bar = 42 if (0); # Not declared, so:
$bar = 3; # Should warn: Global symbol "$bar" requires explicit package name..
}

Dave++

Dave Ljung Madison http://GetDave.com 415.922.2697
- If a tree falls in a forest, and there's nobody around, can I have it? --

p5pRT · 2001-03-12T19:47:29Z

From @tamias

On Mon, Mar 12, 2001 at 11:01:36AM -0800, David Madison wrote:

There's a thread on the topic itself at
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg00686.html

Fine enough, but then I claim that this is a bug:

-------------------------
use strict;

sub fu {
my $bar = 42 if (0); # Not declared, so:
$bar = 3; # Should warn: Global symbol "$bar" requires explicit package name..

That is not correct. Please review the previous thread again.

$bar is declared at compile time, but is not reset at runtime.

Ronald

p5pRT · 2001-03-13T03:41:33Z

From [Unknown Contact. See original ticket]

On Fri, Mar 09, 2001 at 04:39:00PM -0800, Peter Scott wrote:

This is well-known behavior and arguably not a bug. my() has compile-time
and run-time effects. Do a search for "Tom Christiansen" and "who says
Perl doesn't have statics?" and you may turn up a previous thread :-)

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

Michael

p5pRT · 2001-03-13T04:59:03Z

From @simoncozens

On Tue, Mar 13, 2001 at 11:41:21AM +0000, Michael Stevens wrote:

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

We expect people not to do things that don't make sense, and not to be
surprised if they do.

p5pRT · 2001-03-13T11:09:42Z

From @Abigail

On Tue, Mar 13, 2001 at 12:58:47PM +0000, Simon Cozens wrote:

On Tue, Mar 13, 2001 at 11:41:21AM +0000, Michael Stevens wrote:

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

We expect people not to do things that don't make sense, and not to be
surprised if they do.

I don't think it makes sense to tell people that what they did doesn't
make sense if they ask how/why it works and whether that's a bug or
intended behaviour.

It would be very nice if p5p (or the pumpking, or Larry (if he's around))
could at least acknowledge whether something is a bug or intended behaviour.

A "what you did doesn't make sense" is less than useful, and not very
Perlesque.

Abigail

p5pRT · 2001-03-13T11:14:34Z

From @jhi

On Tue, Mar 13, 2001 at 08:11:07PM +0100, abigail@foad.org wrote:

On Tue, Mar 13, 2001 at 12:58:47PM +0000, Simon Cozens wrote:

On Tue, Mar 13, 2001 at 11:41:21AM +0000, Michael Stevens wrote:

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

We expect people not to do things that don't make sense, and not to be
surprised if they do.

I don't think it makes sense to tell people that what they did doesn't
make sense if they ask how/why it works and whether that's a bug or
intended behaviour.

It would be very nice if p5p (or the pumpking, or Larry (if he's around))
could at least acknowledge whether something is a bug or intended behaviour.

Well, I think "my ... if 0" is a bug. Well, not a bug as in
unexpected negative behaviour. It exhibits certain behaviour and some
people think it's positive behaviour. I think it's accidental and
shouldn't be depended on. If we want 'statics', let's have them by
design, not be accident.

A "what you did doesn't make sense" is less than useful, and not very
Perlesque.

Abigail

p5pRT · 2001-03-13T11:39:38Z

From @Abigail

On Tue, Mar 13, 2001 at 01:13:35PM -0600, Jarkko Hietaniemi wrote:

On Tue, Mar 13, 2001 at 08:11:07PM +0100, abigail@foad.org wrote:

On Tue, Mar 13, 2001 at 12:58:47PM +0000, Simon Cozens wrote:

On Tue, Mar 13, 2001 at 11:41:21AM +0000, Michael Stevens wrote:

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

We expect people not to do things that don't make sense, and not to be
surprised if they do.

I don't think it makes sense to tell people that what they did doesn't
make sense if they ask how/why it works and whether that's a bug or
intended behaviour.

It would be very nice if p5p (or the pumpking, or Larry (if he's around))
could at least acknowledge whether something is a bug or intended behaviour.

Well, I think "my ... if 0" is a bug. Well, not a bug as in
unexpected negative behaviour. It exhibits certain behaviour and some
people think it's positive behaviour. I think it's accidental and
shouldn't be depended on. If we want 'statics', let's have them by
design, not be accident.

Can I then suggest we officially declare this as deprecated and that
its behaviour might go away without notice in some future version of Perl?

Abigail

p5pRT · 2001-03-13T11:55:16Z

From @jhi

On Tue, Mar 13, 2001 at 08:42:05PM +0100, abigail@foad.org wrote:

On Tue, Mar 13, 2001 at 01:13:35PM -0600, Jarkko Hietaniemi wrote:

On Tue, Mar 13, 2001 at 08:11:07PM +0100, abigail@foad.org wrote:

On Tue, Mar 13, 2001 at 12:58:47PM +0000, Simon Cozens wrote:

On Tue, Mar 13, 2001 at 11:41:21AM +0000, Michael Stevens wrote:

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

We expect people not to do things that don't make sense, and not to be
surprised if they do.

I don't think it makes sense to tell people that what they did doesn't
make sense if they ask how/why it works and whether that's a bug or
intended behaviour.

It would be very nice if p5p (or the pumpking, or Larry (if he's around))
could at least acknowledge whether something is a bug or intended behaviour.

Well, I think "my ... if 0" is a bug. Well, not a bug as in
unexpected negative behaviour. It exhibits certain behaviour and some
people think it's positive behaviour. I think it's accidental and
shouldn't be depended on. If we want 'statics', let's have them by
design, not be accident.

Can I then suggest we officially declare this as deprecated and that
its behaviour might go away without notice in some future version of Perl?

I will integrate doc/parser-lexical-warning patches to that effect.

p5pRT · 2001-03-14T00:46:21Z

From @sciurius

abigail@foad.org writes:

Can I then suggest we officially declare this as deprecated and that
its behaviour might go away without notice in some future version of
Perl?

This reminds me...

Can someone please turn the >3 args open into a syntax / run time
error until it is fixed?

open (FH, "-|", "deleteallfiles", "-tempfilesonly")

still silently calls the "deleteallfiles" program without passing the
"-tempfilesonly" argument.

-- Johan

p5pRT · 2001-03-14T02:37:34Z

From [Unknown Contact. See original ticket]

Johan Vromans <jvromans@squirrel.nl> writes:

abigail@foad.org writes:

Can I then suggest we officially declare this as deprecated and that
its behaviour might go away without notice in some future version of
Perl?

This reminds me...

Can someone please turn the >3 args open into a syntax / run time
error until it is fixed?

It is on the list. Patches welcome.

open (FH, "-|", "deleteallfiles", "-tempfilesonly")

still silently calls the "deleteallfiles" program without passing the
"-tempfilesonly" argument.

-- Johan

p5pRT · 2001-03-14T05:54:24Z

From @gbarr

On Tue, Mar 13, 2001 at 01:13:35PM -0600, Jarkko Hietaniemi wrote:

Well, I think "my ... if 0" is a bug. Well, not a bug as in
unexpected negative behaviour. It exhibits certain behaviour and some
people think it's positive behaviour. I think it's accidental and
shouldn't be depended on. If we want 'statics', let's have them by
design, not be accident.

Let me just say I agree, so some extent. And that I have spent many hours
in the past trying to fix this problem and not succeeding too well. But it is much much more difficult
that you might expect. I managed to catch the common cases, but the parser allows
many more variations that are not so easy to find and fixup.

For instance

($x, my $y) = (...) if 0;

makes a very different op tree, and even

($x, my $y) = (...) while (...);

is even more weird.

In the end I took the approach that if you cannot locate and fix
all of these, then its not worth fixing the rest.

Graham.

p5pRT · 2001-03-14T08:46:48Z

From @nwc10

On Tue, Mar 13, 2001 at 08:11:07PM +0100, abigail@foad.org wrote:

On Tue, Mar 13, 2001 at 12:58:47PM +0000, Simon Cozens wrote:

On Tue, Mar 13, 2001 at 11:41:21AM +0000, Michael Stevens wrote:

Is this actually documented anywhere? Or do we expected people to
read perl5-porters to know how their perl programs will behave?

We expect people not to do things that don't make sense, and not to be
surprised if they do.

I don't think it makes sense to tell people that what they did doesn't
make sense if they ask how/why it works and whether that's a bug or
intended behaviour.

It would be very nice if p5p (or the pumpking, or Larry (if he's around))
could at least acknowledge whether something is a bug or intended behaviour.

A "what you did doesn't make sense" is less than useful, and not very
Perlesque.

And no use to anyone crafting cryptic one liners, as Abigail^Wthey won't
know whether that feature will be around in future versions.

Nicholas Clark

p5pRT closed this as completed Nov 28, 2003

p5pRT added Severity Low distro-Linux labels Oct 18, 2019

Grinnz added the my-in-false-conditional label Aug 18, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

my $var = val if (..) doesn't work properly #3548

my $var = val if (..) doesn't work properly #3548

p5pRT commented Mar 9, 2001

p5pRT commented Mar 9, 2001

p5pRT commented Mar 9, 2001

p5pRT commented Mar 9, 2001

p5pRT commented Mar 10, 2001

p5pRT commented Mar 10, 2001

p5pRT commented Mar 10, 2001

p5pRT commented Mar 10, 2001

p5pRT commented Mar 12, 2001

p5pRT commented Mar 12, 2001

p5pRT commented Mar 13, 2001

p5pRT commented Mar 13, 2001

p5pRT commented Mar 13, 2001

p5pRT commented Mar 13, 2001

p5pRT commented Mar 13, 2001

p5pRT commented Mar 13, 2001

p5pRT commented Mar 14, 2001

p5pRT commented Mar 14, 2001

p5pRT commented Mar 14, 2001

p5pRT commented Mar 14, 2001

Navigation Menu

my $var = val if (..) doesn't work properly #3548

my $var = val if (..) doesn't work properly #3548

Comments

p5pRT commented Mar 9, 2001

p5pRT commented Mar 9, 2001

From madison@transmeta.com

p5pRT commented Mar 9, 2001

From @pjscott

p5pRT commented Mar 9, 2001

From @pjscott

p5pRT commented Mar 10, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Mar 10, 2001

From @jhi

p5pRT commented Mar 10, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Mar 10, 2001

From @pjscott

p5pRT commented Mar 12, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Mar 12, 2001

From @tamias

p5pRT commented Mar 13, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Mar 13, 2001

From @simoncozens

p5pRT commented Mar 13, 2001

From @Abigail

p5pRT commented Mar 13, 2001

From @jhi

p5pRT commented Mar 13, 2001

From @Abigail

p5pRT commented Mar 13, 2001

From @jhi

p5pRT commented Mar 14, 2001

From @sciurius

p5pRT commented Mar 14, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Mar 14, 2001

From @gbarr

p5pRT commented Mar 14, 2001

From @nwc10