Skip to content
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

Jump to bottom

Inconsistent & nonintuitive initialization of private "my" variables in a scoped code block #11285

Closed
p5pRT opened this issue Apr 28, 2011 · 4 comments
Closed

Inconsistent & nonintuitive initialization of private "my" variables in a scoped code block #11285

p5pRT opened this issue Apr 28, 2011 · 4 comments
Labels
distro-Linux lexical/scope/closure my-in-false-conditional type-core

Comments

@p5pRT
Copy link

p5pRT commented Apr 28, 2011

Migrated from rt.perl.org#89514 (status was 'rejected')

Searchable as RT89514$
@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2011

From perl@g.zazu.com

Created by perl@g.zazu.com

There seems to be a bug (or at least mis-documented non-intuitive handling)
with persisting scoped private "my" variables. The following code snippet
illustrates the perl private variable misbehavior​:

#######################

use strict;

print "Run 1​:\n";
foreach (1 .. 2) {
  my $var;
  print "var = $var\n";
  $var = 5;
}

print "\nRun 2​:\n";
foreach (1 .. 2) {
  my $var = 1 if 2 == 3;
  print "var = $var\n";
  $var = 5;
}

########################

Run 1​:
var =
var =

Run 2​:
var =
var = 5

########################

Note that $var has a previous value in Run 2 on the second pass into the loop.
Whether this is an actual perl language bug or not, it is certainly
counter-intuitive​: in other languages (e.g., C, C++, java), this would be a
stack variable that is allocated on entry into the code block and released at
the end of the code block. Perl seems to be using a more permanent heap
variable that should be garbage-collected when refcount=0 but is being reused.
In case the above code snippet doesn't clearly show that the refcount = 0 at
the top of the loop block, perhaps the following more clearly illustrates the
misbehavior (the run results matches above)​:

########################

foreach (1 .. 2) {
  &try;
}

sub try
{
  my $var = 1 if 2 == 3;
  print "var = $var\n";
  $var = 5;
}

########################

I later discovered that the perl behavior is even more inconsistent than
implied by the above example. The following code snippet illustrates the
additonal twist​:

########################

use strict;

foreach my $i (-3 .. 3) {
  my $var = 2 if !$i;
  print "var​: $var \t(i​: $i)\n";
  $var = 5;
}

########################

var​: (i​: -3)
var​: 5 (i​: -2)
var​: 5 (i​: -1)
var​: 2 (i​: 0)
var​: (i​: 1)
var​: 5 (i​: 2)
var​: 5 (i​: 3)

########################

Notice that the first three iterations above exhibit the same behavior as noted
previously. Then, the 4th iteration (i=0) properly executes the expected
conditional initialization. The twist is with the 5th iteration (i=1), which
again properly initializes to undef when the conditional fails, only to return
to the misbehavior after that (i=2). So, it's not simply the case that the
private variable always persists with the previous value unless the conditional
initialization occurs.

Perl Info 

Flags:
    category=core
    severity=high

This perlbug was built using Perl 5.10.1 in the Fedora build system.
It is being executed now by Perl 5.10.1 - Tue Apr  5 07:59:51 UTC 2011.

Site configuration information for perl 5.10.1:

Configured by Red Hat, Inc. at Tue Apr  5 07:59:51 UTC 2011.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-71.14.1.el6.x86_64, archname=x86_64-linux-thread-multi
    uname='linux x86-06.phx2.fedoraproject.org 2.6.32-71.14.1.el6.x86_64 #1 smp wed jan 5 17:01:01 est 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5 -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoen!
 t_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dotherlibdirs=/usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi:/usr/local/lib/perl5/site_perl/5.10.0:/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi:/usr/lib/perl5/vendor_perl:/usr/lib/perl5/site_perl'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.5 20101112 (Red Hat 4.4.5-2)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

Locally applied patches:
    


@INC for perl 5.10.1:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5
    /usr/share/perl5
    /usr/lib64/perl5
    /usr/share/perl5
    /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
    /usr/local/lib/perl5/site_perl/5.10.0
    /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.10.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/site_perl
    .


Environment for perl 5.10.1:
    HOME=/home/glenn
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Apr 29, 2011

From @iabyn

On Thu, Apr 28, 2011 at 03​:24​:30PM -0700, perl@​g.zazu.com wrote​:

There seems to be a bug (or at least mis-documented non-intuitive handling)
with persisting scoped private "my" variables. The following code snippet
illustrates the perl private variable misbehavior​:

To quote from perlsyn​:

  B<NOTE​:> The behaviour of a C<my> statement modified with a statement
  modifier conditional or loop construct (e.g. C<my $x if ...>) is
  B<undefined>. The value of the C<my> variable may be C<undef>, any
  previously assigned value, or possibly anything else. Don't rely on
  it. Future versions of perl might do something different from the
  version of perl you try it out on. Here be dragons.

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
  -- Lady Croom, "Arcadia"

@p5pRT
Copy link
Author

p5pRT commented Apr 29, 2011

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Apr 29, 2011

@iabyn - Status changed from 'open' to 'rejected'

@p5pRT p5pRT closed this as completed Apr 29, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
distro-Linux lexical/scope/closure my-in-false-conditional type-core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Grinnz @p5pRT