From chris@mail.piyeepress.com

Created by chris@mail.piyeepress.com

Open should return false when using $1 as a file handle considering $1 is a read-only variable​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"'

It does not. Here's the output after dumping $1​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"; use Data​::Dumper; print Dumper \$1;'
$VAR1 = \undef;

Here is when a variable named "$foo" is used as a file handle​:

$ perl -we'open $foo, "/dev/null" or die "open​: $!"; use Data​::Dumper; print Dumper \$foo;'
$VAR1 = \\*{'​::$foo'};

Attempting to assign to $1 should raise the "Modification of a read-only value attempted" exception, right?

I find the fact that open doesn't return false and set $! unexpected behavior and would classify the behavior as a bug.

Thanks,

Chris Angell
chris@​chrisangell.com

Flags:
    category=core
    severity=medium

This perlbug was built using Perl v5.8.0 - Wed Sep  3 05:15:53 PDT 2003
It is being executed now by  Perl v5.8.5 - Thu Aug  5 09:52:16 PDT 2004.

Site configuration information for perl v5.8.5:

Configured by chris at Thu Aug  5 09:52:16 PDT 2004.

Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
  Platform:
    osname=openbsd, osvers=3.3, archname=OpenBSD.i386-openbsd-multi
    uname='openbsd mail.piyeepress.com 3.3 bsdkern#0 i386 '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef 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 ='-fno-strict-aliasing -pipe -I/usr/local/include',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='2.95.3 20010125 (prerelease, propolice)', gccosandvers='openbsd3.3'
    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 /usr/lib
    libs=-lm -lutil -lc
    perllibs=-lm -lutil -lc
    libc=/usr/lib/libc.so.29.0, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags=' '
    cccdlflags='-DPIC -fPIC ', lddlflags='-shared -fPIC  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.5:
    /usr/local/lib/perl5/5.8.5/OpenBSD.i386-openbsd-multi
    /usr/local/lib/perl5/5.8.5
    /usr/local/lib/perl5/site_perl/5.8.5/OpenBSD.i386-openbsd-multi
    /usr/local/lib/perl5/site_perl/5.8.5
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.8.5:
    HOME=/home/chris
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/ksh

From @iabyn

On Wed, Sep 29, 2004 at 04​:43​:50PM -0000, Chris Kelly wrote​:

Open should return false when using $1 as a file handle considering $1 is a read-only variable​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"'

Actually, it should die, in a similar fashion to the following​:

  $ perl585 -we '$1->{foo}=1'
  Modification of a read-only value attempted at -e line 1.

since both involve autovivification of a readonly value.

The change below to the development version of Perl fixes this.

Dave.

--
The warp engines start playing up a bit, but seem to sort themselves out
after a while without any intervention from boy genius Wesley Crusher.
  -- Things That Never Happen in "Star Trek" #17

Change 23342 by davem@​davem-percy on 2004/09/30 20​:51​:31

  [perl #31767] open $1, "file" doesn't raise an exception

Affected files ...

... //depot/perl/pp.c#426 edit
... //depot/perl/t/io/open.t#41 edit

Differences ...

==== //depot/perl/pp.c#426 (text) ====

@​@​ -159,6 +159,8 @​@​
  /* If this is a 'my' scalar and flag is set then vivify
  * NI-S 1999/05/07
  */
+ if (SvREADONLY(sv))
+ Perl_croak(aTHX_ PL_no_modify);
  if (PL_op->op_private & OPpDEREF) {
  char *name;
  GV *gv;

==== //depot/perl/t/io/open.t#41 (xtext) ====

@​@​ -12,7 +12,7 @​@​
$Is_VMS = $^O eq 'VMS';
$Is_MacOS = $^O eq 'MacOS';

-plan tests => 107;
+plan tests => 108;

my $Perl = which_perl();

@​@​ -315,3 +315,9 @​@​
  'sub f { open(my $fh, "xxx"); $fh = "f"; } f; f;print "ok"',
  'ok', { stderr => 1 },
  '#29102​: Crash on assignment to lexical filehandle');
+
+# [perl #31767] Using $1 as a filehandle via open $1, "file" doesn't raise
+# an exception
+
+eval { open $99, "foo" };
+like($@​, qr/Modification of a read-only value attempted/, "readonly fh");

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

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

From @cpansprout

On Thu Sep 30 14​:14​:22 2004, davem@​iabyn.com wrote​:

On Wed, Sep 29, 2004 at 04​:43​:50PM -0000, Chris Kelly wrote​:

Open should return false when using $1 as a file handle considering
$1 is a read-only variable​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"'

Actually, it should die, in a similar fashion to the following​:

$ perl585 \-we '$1\->\{foo\}=1'
Modification of a read\-only value attempted at \-e line 1\.

since both involve autovivification of a readonly value.

The change below to the development version of Perl fixes this.

And causes this bug, which I’m about to fix shortly​:

$ perl -lwe 'close $x; Internals​::SvREADONLY($x,1);
close $x'
Use of uninitialized value $x in ref-to-glob cast at -e line 1.
Modification of a read-only value attempted at -e line 1.

I wasn’t trying to modify it.

From [Unknown Contact. See original ticket]

On Thu Sep 30 14​:14​:22 2004, davem@​iabyn.com wrote​:

On Wed, Sep 29, 2004 at 04​:43​:50PM -0000, Chris Kelly wrote​:

Open should return false when using $1 as a file handle considering
$1 is a read-only variable​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"'

Actually, it should die, in a similar fashion to the following​:

$ perl585 \-we '$1\->\{foo\}=1'
Modification of a read\-only value attempted at \-e line 1\.

since both involve autovivification of a readonly value.

The change below to the development version of Perl fixes this.

And causes this bug, which I’m about to fix shortly​:

$ perl -lwe 'close $x; Internals​::SvREADONLY($x,1);
close $x'
Use of uninitialized value $x in ref-to-glob cast at -e line 1.
Modification of a read-only value attempted at -e line 1.

I wasn’t trying to modify it.

From @davidnicol

so symbolic reference is out, then?

$ perl -le '"​:FH​:"=~/(\w\w)/ and open $1, ">&STDOUT"; print FH 99'
99

That's going to stop working?

On Tue, Aug 23, 2011 at 4​:23 PM, Father Chrysostomos via RT <
perlbug-comment@​perl.org> wrote​:

On Thu Sep 30 14​:14​:22 2004, davem@​iabyn.com wrote​:

On Wed, Sep 29, 2004 at 04​:43​:50PM -0000, Chris Kelly wrote​:

Open should return false when using $1 as a file handle considering
$1 is a read-only variable​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"'

Actually, it should die, in a similar fashion to the following​:

$ perl585 \-we '$1\->\{foo\}=1'
Modification of a read\-only value attempted at \-e line 1\.

since both involve autovivification of a readonly value.

The change below to the development version of Perl fixes this.

And causes this bug, which I’m about to fix shortly​:

$ perl -lwe 'close $x; Internals​::SvREADONLY($x,1);
close $x'
Use of uninitialized value $x in ref-to-glob cast at -e line 1.
Modification of a read-only value attempted at -e line 1.

I wasn’t trying to modify it.

--
"The tools expect that they have full, unlimited control of the hardware."
-- Intel Corporation

From @cpansprout

On Tue Aug 23 14​:23​:57 2011, sprout wrote​:

On Thu Sep 30 14​:14​:22 2004, davem@​iabyn.com wrote​:

On Wed, Sep 29, 2004 at 04​:43​:50PM -0000, Chris Kelly wrote​:

Open should return false when using $1 as a file handle considering
$1 is a read-only variable​:

$ perl -we'open $1, "/dev/null" or die "open​: $!"'

Actually, it should die, in a similar fashion to the following​:

$ perl585 \-we '$1\->\{foo\}=1'
Modification of a read\-only value attempted at \-e line 1\.

since both involve autovivification of a readonly value.

The change below to the development version of Perl fixes this.

And causes this bug, which I’m about to fix shortly​:

$ perl -lwe 'close $x; Internals​::SvREADONLY($x,1);
close $x'
Use of uninitialized value $x in ref-to-glob cast at -e line 1.
Modification of a read-only value attempted at -e line 1.

I wasn’t trying to modify it.

Now fixed with commit ce74145.