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

can't write open() wrapper without affecting how the FH is parsed #7487

Open
p5pRT opened this issue Sep 1, 2004 · 8 comments
Open

can't write open() wrapper without affecting how the FH is parsed #7487

p5pRT opened this issue Sep 1, 2004 · 8 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 1, 2004

Migrated from rt.perl.org#31422 (status was 'open')

Searchable as RT31422$

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 2004

From andrew@pimlott.net

Created by andrew@pimlott.net

I tried to write a wrapper for open​:

  sub myopen (*$$) {
  my ($fh, $mode, $file) = @​_;
  open($fh, $mode, $file)
  }

However, using it has unexpected and subtle side effects on how the opened
filehandle is interpreted by the parser.

  myopen OUT, '>', 'out' or die $!;
  print OUT "hey\n";
  close OUT;

works fine. But

  sub FOO​::bar { "hey\n" }
  myopen OUT, '>', 'out' or die $!;
  print OUT FOO->bar;
  close OUT;

gives Can't locate object method "OUT" via package "FOO", and with -w also
gives Name "main​::OUT" used only once​: possible typo. This code works fine
with a normal open.

Evidently, the parser has some heuristics for interpreting barewords, which
this code is fooling. Unfortunately, it means that you can't write a
drop-in wrapper for open. Perhaps the parser should use the * prototype as
a hint that OUT is a filehandle, and should be interpreted as such in the
rest of the code. Or maybe someone who really understands the heuristics
can suggest a better solution. I was quite shocked that

  print OUT FOO->bar;

is parsed as

  print ((OUT FOO)->bar)

(am I correct?), even if OUT isn't known to be a filehandle. I would think
that any bareword following print should be considered a filehandle. Maybe
this is the real problem.

Andrew

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.4:

Configured by Debian Project at Wed May 12 00:32:16 EST 2004.

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
  Platform:
    osname=linux, osvers=2.4.26-ti1211, archname=i386-linux-thread-multi
    uname='linux kosh 2.4.26-ti1211 #1 sat apr 24 14:46:58 est 2004 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.4 -Dsitearch=/usr/local/lib/perl/5.8.4 -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 -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef 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 -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.3.3 (Debian 20040429)', 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
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.4
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.4:
    /home/andrew/lib/perl
    /home/andrew/local/lib/perl
    /etc/perl
    /usr/local/lib/perl/5.8.4
    /usr/local/share/perl/5.8.4
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8
    /usr/share/perl/5.8
    /usr/local/lib/site_perl
    .


Environment for perl v5.8.4:
    HOME=/home/andrew
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/andrew/bin:/usr/sbin:/sbin:/home/andrew/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
    PERL5LIB=/home/andrew/lib/perl:/home/andrew/local/lib/perl
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

@p5pRT
Copy link
Author

p5pRT commented Dec 7, 2011

From @jkeenan

On Wed Sep 01 10​:29​:40 2004, andrew@​pimlott.net wrote​:

I tried to write a wrapper for open​:

sub myopen \(\*$$\) \{
    my \($fh\, $mode\, $file\) = @​\_;
    open\($fh\, $mode\, $file\)
\}

However, using it has unexpected and subtle side effects on how the
opened
filehandle is interpreted by the parser.

myopen OUT\, '>'\, 'out' or die $\!;
print OUT "hey\\n";
close OUT;

works fine. But

sub FOO​::bar \{ "hey\\n" \}
myopen OUT\, '>'\, 'out' or die $\!;
print OUT FOO\->bar;
close OUT;

gives Can't locate object method "OUT" via package "FOO", and with -w
also
gives Name "main​::OUT" used only once​: possible typo. This code works
fine
with a normal open.
[snip]

I believe the program attached, 31442.pl, reproduces your sample code.
However, when I run it I don't reproduce either the failure or the
warning you cite.

(Of course, when I try to run this under 'use strict;', I start to
encounter problems. But, then again, I don't understand the need to
write a wrapper for 'open'. And it's been a long time since I wrote a
program with global filehandles rather than lexically scoped filehandles.)

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Dec 7, 2011

From @jkeenan

31442.pl

@p5pRT
Copy link
Author

p5pRT commented Dec 7, 2011

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

@p5pRT
Copy link
Author

p5pRT commented Dec 7, 2011

From @cpansprout

On Tue Dec 06 19​:08​:12 2011, jkeenan wrote​:

On Wed Sep 01 10​:29​:40 2004, andrew@​pimlott.net wrote​:

I tried to write a wrapper for open​:

sub myopen \(\*$$\) \{
    my \($fh\, $mode\, $file\) = @​\_;
    open\($fh\, $mode\, $file\)
\}

However, using it has unexpected and subtle side effects on how the
opened
filehandle is interpreted by the parser.

myopen OUT\, '>'\, 'out' or die $\!;
print OUT "hey\\n";
close OUT;

works fine. But

sub FOO​::bar \{ "hey\\n" \}
myopen OUT\, '>'\, 'out' or die $\!;
print OUT FOO\->bar;
close OUT;

gives Can't locate object method "OUT" via package "FOO", and with -w
also
gives Name "main​::OUT" used only once​: possible typo. This code works
fine
with a normal open.
[snip]

I believe the program attached, 31442.pl, reproduces your sample code.
However, when I run it I don't reproduce either the failure or the
warning you cite.

This is one of my pet peeves. The (*) prototype isn’t anything like any
built-in function, even though perl56delta says​:

  More functional bareword prototype (*)
  Bareword prototypes have been rationalized to enable them to be
used to
  override builtins that accept barewords and interpret them in a
special
  way, such as "require" or "do".

(Of course, when I try to run this under 'use strict;', I start to
encounter problems. But, then again, I don't understand the need to
write a wrapper for 'open'.

See autodie, which I consider broken for this very reason (among others).

And it's been a long time since I wrote a
program with global filehandles rather than lexically scoped filehandles.)

Thank you very much.
Jim Keenan

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Dec 7, 2011

From andrew@pimlott.net

Excerpts from James E Keenan via RT's message of Tue Dec 06 19​:08​:12 -0800 2011​:

On Wed Sep 01 10​:29​:40 2004, andrew@​pimlott.net wrote​:

[snip]

I believe the program attached, 31442.pl, reproduces your sample code.
However, when I run it I don't reproduce either the failure or the
warning you cite.

(Of course, when I try to run this under 'use strict;', I start to
encounter problems. But, then again, I don't understand the need to
write a wrapper for 'open'. And it's been a long time since I wrote a
program with global filehandles rather than lexically scoped filehandles.)

Wow, I have no idea why I filed that bug (in 2004) either! Your
follow-up is admirable. :-)

Andrew

@p5pRT
Copy link
Author

p5pRT commented Dec 8, 2011

From @jkeenan

On Wed Dec 07 11​:32​:14 2011, andrew@​pimlott.net wrote​:

Wow, I have no idea why I filed that bug (in 2004) either! Your
follow-up is admirable. :-)

Well, I'm trying to make sure everyone who takes the time to file a bug
report gets a response from a human in, say, eight years or less. ;-)

I'll take this ticket and hold it open for seven days in case you want
to file an updated report. Otherwise, we'll close it in a week's time.

Thanks for your quick response.

Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Dec 8, 2011

From @cpansprout

On Wed Dec 07 18​:16​:22 2011, jkeenan wrote​:

On Wed Dec 07 11​:32​:14 2011, andrew@​pimlott.net wrote​:

Wow, I have no idea why I filed that bug (in 2004) either! Your
follow-up is admirable. :-)

Well, I'm trying to make sure everyone who takes the time to file a bug
report gets a response from a human in, say, eight years or less. ;-)

I'll take this ticket and hold it open for seven days in case you want
to file an updated report. Otherwise, we'll close it in a week's time.

I may have misunderstood the original report, but in any case there is a
bug here.

I think this report should stay open until we figure out some way to let
perl subs override open() with the same syntax, or decide that we’re not
going to.

  open(<FH>, $file); # syntax error
  myopen(<FH>, $file); # silently the wrong thing

  sub foo;
  open(foo, $file); # calls foo()
  myopen(foo, $file); # same as myopen("foo"...)

  sub foo() { 0 }
  open(foo, $file); # open(0, $file);
  myopen(foo, $file); # same (inconsistent with example above)

--

Father Chrysostomos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants