lib/vars.pm setting $^H?

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

Searchable as RT130674$

@hvds

From @hvds

Created by @hvds

I just noticed this in lib/vars.pm:
} elsif (($^H &= strict::bits('vars'))) {
^^
which seems a bit weird. The check was introduced in 2000 by 1d76c68, and
survived numerous further edits in 2002, but hasn't been touched since then.

I suspect it should just be:
} elsif ($^H & strict::bits('vars')) {
but I'm not sure; if it is correct, it'd be useful to add a comment
explaining why it's sane.

Perl Info


Flags:
    category=library
    severity=low
    module=vars

Site configuration information for perl 5.25.10:

Configured by hv at Mon Jan 23 20:29:32 GMT 2017.

Summary of my perl5 (revision 5 version 25 subversion 10) configuration:
  Commit id: e18c4116c82b2027a1e5d4e6b9a7214d60779053
  Platform:
    osname=linux
    osvers=3.13.0-101-generic
    archname=x86_64-linux
    uname='linux shad2 3.13.0-101-generic #148-ubuntu smp thu oct 20 22:08:32 utc 2016 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Dcc=gcc -Dprefix=/opt/blead-d0 -Doptimize=-g -O0 -DDEBUGGING -Dusedevel -Uversiononly'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    bincompat5005=undef
  Compiler:
    cc='gcc'
    ccflags ='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-g -O0'
    cppflags='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion=''
    gccversion='4.8.4'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    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 -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64
    libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.19.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.19'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E'
    cccdlflags='-fPIC'
    lddlflags='-shared -g -O0 -L/usr/local/lib -fstack-protector'



@INC for perl 5.25.10:
    /opt/blead-d0/lib/perl5/site_perl/5.25.10/x86_64-linux
    /opt/blead-d0/lib/perl5/site_perl/5.25.10
    /opt/blead-d0/lib/perl5/5.25.10/x86_64-linux
    /opt/blead-d0/lib/perl5/5.25.10
    /opt/blead-d0/lib/perl5/site_perl/5.25.8
    /opt/blead-d0/lib/perl5/site_perl


Environment for perl 5.25.10:
    HOME=/home/hv
    LANG=C
    LANGUAGE=en_GB:en
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=<elided>
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@tonycoz

From @tonycoz

On Mon, 30 Jan 2017 09:45:53 -0800, hv wrote:

I just noticed this in lib/vars.pm:
} elsif (($^H &= strict::bits('vars'))) {
^^
which seems a bit weird. The check was introduced in 2000 by 1d76c68,
and
survived numerous further edits in 2002, but hasn't been touched since
then.

I suspect it should just be:
} elsif ($^H & strict::bits('vars')) {
but I'm not sure; if it is correct, it'd be useful to add a comment
explaining why it's sane.

It's broken, since it removes non-vars strictness:

./perl -Ilib -e 'use strict "refs"; use vars qw($foo$); my $x= "abc"; print $$x'

(no error from the symbolic ref)

The attached fixes it, but we're in a "no changes in behaviour" freeze. This has been broken long enough that I could easily see code out there this fix would break.

Tony

@tonycoz

From @tonycoz

0001-perl-130674-don-t-modify-H.patch

From 0bba1946d4e5d7551607c413320146b6cc4085a6 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Wed, 1 Feb 2017 16:31:02 +1100
Subject: (perl #130674) don't modify $^H

This could remove non-vars strictness from the caller.
---
 lib/vars.pm | 4 ++--
 lib/vars.t  | 9 ++++++++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/lib/vars.pm b/lib/vars.pm
index 6ca6bb4..fc95c77 100644
--- a/lib/vars.pm
+++ b/lib/vars.pm
@@ -2,7 +2,7 @@ package vars;
 
 use 5.006;
 
-our $VERSION = '1.03';
+our $VERSION = '1.04';
 
 use warnings::register;
 use strict qw(vars subs);
@@ -20,7 +20,7 @@ sub import {
 		    Carp::croak("Can't declare individual elements of hash or array");
 		} elsif (warnings::enabled() and length($sym) == 1 and $sym !~ tr/a-zA-Z//) {
 		    warnings::warn("No need to declare built-in vars");
-		} elsif  (($^H &= strict::bits('vars'))) {
+		} elsif  (($^H & strict::bits('vars'))) {
 		    require Carp;
 		    Carp::croak("'$_' is not a valid variable name under strict vars");
 		}
diff --git a/lib/vars.t b/lib/vars.t
index 3075f8e..9b9822c 100644
--- a/lib/vars.t
+++ b/lib/vars.t
@@ -8,7 +8,7 @@ BEGIN {
 
 $| = 1;
 
-print "1..27\n";
+print "1..28\n";
 
 # catch "used once" warnings
 my @warns;
@@ -103,3 +103,10 @@ print "${e}ok 26\n";
 $e = !(grep(/^Global symbol "\%w" requires explicit package name/, @errs))
 			&& 'not ';
 print "${e}ok 27\n";
+
+{
+    no strict;
+    eval 'use strict "refs"; my $zz = "abc"; use vars qw($foo$); my $y = $$zz;';
+    $e = $@ ? "" : "not ";
+    print "${e}ok 28 # use vars error check modifying other strictness\n";
+}
-- 
2.1.4

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

@tonycoz

From @tonycoz

On Tue, 31 Jan 2017 21:33:58 -0800, tonyc wrote:

On Mon, 30 Jan 2017 09:45:53 -0800, hv wrote:

I just noticed this in lib/vars.pm:
} elsif (($^H &= strict::bits('vars'))) {
^^
which seems a bit weird. The check was introduced in 2000 by
1d76c68,
and
survived numerous further edits in 2002, but hasn't been touched
since
then.

I suspect it should just be:
} elsif ($^H & strict::bits('vars')) {
but I'm not sure; if it is correct, it'd be useful to add a comment
explaining why it's sane.

It's broken, since it removes non-vars strictness:

./perl -Ilib -e 'use strict "refs"; use vars qw($foo$); my $x= "abc";
print $$x'

(no error from the symbolic ref)

The attached fixes it, but we're in a "no changes in behaviour"
freeze. This has been broken long enough that I could easily see code
out there this fix would break.

Applied as eda3f95 with some minor changes.

Tony

@tonycoz

@tonycoz - Status changed from 'open' to 'pending release'

@khwilliamson

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.30.0, this and 160 other issues have been
resolved.

Perl 5.30.0 may be downloaded via:
https://metacpan.org/release/XSAWYERX/perl-5.30.0

If you find that the problem persists, feel free to reopen this ticket.

@khwilliamson

@khwilliamson - Status changed from 'pending release' to 'resolved'

Navigation Menu

Repository navigation

lib/vars.pm setting $^H? #15851

From @hvds

Created by @hvds

From @tonycoz

From @tonycoz

From @tonycoz

From @khwilliamson

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

lib/vars.pm setting $^H? #15851

Description

Activity

p5pRT commented on Jan 30, 2017

From @hvds

Created by @hvds

p5pRT commented on Feb 1, 2017

From @tonycoz

p5pRT commented on Feb 1, 2017

From @tonycoz

p5pRT commented on Feb 1, 2017

p5pRT commented on Sep 26, 2018

From @tonycoz

p5pRT commented on Sep 26, 2018

p5pRT commented on May 22, 2019

From @khwilliamson

p5pRT commented on May 22, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions