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.

Sign up for GitHub

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

eval lexical inheritance nit #9848

Closed
p5pRT opened this issue Aug 24, 2009 · 4 comments
Closed

eval lexical inheritance nit #9848

p5pRT opened this issue Aug 24, 2009 · 4 comments
Labels
distro-Linux type-core

Comments

@p5pRT
Copy link

p5pRT commented Aug 24, 2009

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

Searchable as RT68750$
@p5pRT
Copy link
Author

p5pRT commented Aug 24, 2009

From zefram@fysh.org

Created by zefram@fysh.org

In certain situations, the lexical environment immediately inside a
string eval can be different from that immediately outside it​:

$ perl -lwe '$^H{foo} = "zzz"; BEGIN { print $^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef) } }'
undef
zzz

Outside the eval, $^H{foo} is non-existent all through compilation.
That is the lexical environment that should propagate into the eval.
However, my assignment to $^H{foo} at *runtime* turns out to be visible
lexically inside the eval. This does not occur if I put anything into
%^H during outer compilation​:

$ perl -lwe 'BEGIN { $^H{foo} = "wibble" } $^H{foo} = "zzz"; BEGIN { print $^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef) } }'
wibble
wibble
$ perl -lwe 'BEGIN { $^H{bar} = "wibble" } $^H{foo} = "zzz"; BEGIN { print $^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef) } }'
undef
undef

The behaviour is also correct if I set HINT_LOCALIZE_HH manually, which
is probably the underlying reason for assignment to $^H{bar} fixing it​:

$ perl -lwe 'BEGIN { $^H |= 0x20000 } $^H{foo} = "zzz"; BEGIN { print $^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef) } }'
undef
undef

Perl Info 

Flags:
    category=core
    severity=low

Site configuration information for perl 5.10.0:

Configured by Debian Project at Thu Jan  1 12:43:38 UTC 2009.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.26-1-686, archname=i486-linux-gnu-thread-multi
    uname='linux rebekka 2.6.26-1-686 #1 smp mon dec 15 18:15:07 utc 2008 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.3.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/lib64
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0
    gnulibc_version='2.7'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.10.0:
    /etc/perl
    /usr/local/lib/perl/5.10.0
    /usr/local/share/perl/5.10.0
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl
    .


Environment for perl 5.10.0:
    HOME=/home/zefram
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/zefram/pub/i686-pc-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2009

sgc294@internode.on.net - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Nov 7, 2011

From @cpansprout

On Sun Aug 23 17​:31​:31 2009, zefram@​fysh.org wrote​:

In certain situations, the lexical environment immediately inside a
string eval can be different from that immediately outside it​:

$ perl -lwe '$^H{foo} = "zzz"; BEGIN { print $^H{foo}||q(undef) } eval
q{ BEGIN { print $^H{foo}||q(undef) } }'
undef
zzz

Outside the eval, $^H{foo} is non-existent all through compilation.
That is the lexical environment that should propagate into the eval.
However, my assignment to $^H{foo} at *runtime* turns out to be
visible
lexically inside the eval. This does not occur if I put anything into
%^H during outer compilation​:

$ perl -lwe 'BEGIN { $^H{foo} = "wibble" } $^H{foo} = "zzz"; BEGIN {
print $^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef)
} }'
wibble
wibble
$ perl -lwe 'BEGIN { $^H{bar} = "wibble" } $^H{foo} = "zzz"; BEGIN {
print $^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef)
} }'
undef
undef

The behaviour is also correct if I set HINT_LOCALIZE_HH manually,
which
is probably the underlying reason for assignment to $^H{bar} fixing
it​:

$ perl -lwe 'BEGIN { $^H |= 0x20000 } $^H{foo} = "zzz"; BEGIN { print
$^H{foo}||q(undef) } eval q{ BEGIN { print $^H{foo}||q(undef) } }'
undef
undef

Once again, I’ve discovered a bug by reading code, not realising there
is a ticket already.

You may be pleased to know this was fixed by commit bc34412.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 7, 2011

@cpansprout - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Nov 7, 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 type-core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@p5pRT