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

Inappropriate warning for 'my' in 'open' #4186

Closed
p5pRT opened this issue Jul 9, 2001 · 20 comments
Closed

Inappropriate warning for 'my' in 'open' #4186

p5pRT opened this issue Jul 9, 2001 · 20 comments

Comments

@p5pRT
Copy link

p5pRT commented Jul 9, 2001

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

Searchable as RT7250$

@p5pRT
Copy link
Author

p5pRT commented Jul 9, 2001

From @mjdominus

Created by @mjdominus

  perl -we '$file="X"; open my $fh, $file;'

  Parentheses missing around "my" list at -e line 1.

The warning is inappropriate in this context.

A workaround is to write​:

  perl -we '$file="X"; open my $fh, "$file";'

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.1:

Configured by mjd at Mon Apr  9 13:10:50 EDT 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.2.16, archname=i586-linux
    uname='linux plover 2.2.16 #5 wed sep 27 19:05:46 edt 2000 i586 unknown '
    config_args='-des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', 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, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
    libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.1:
    /usr/local/lib/perl5/5.6.1/i586-linux
    /usr/local/lib/perl5/5.6.1
    /usr/local/lib/perl5/site_perl/5.6.1/i586-linux
    /usr/local/lib/perl5/site_perl/5.6.1
    /usr/local/lib/perl5/site_perl/5.6.0/i586-linux
    /usr/local/lib/perl5/site_perl/5.6.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.6.1:
    HOME=/home/mjd
    LANG (unset)
    LANGUAGE (unset)
    LC_ALL=POSIX
    LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib
    LOGDIR (unset)
    PATH=/home/mjd/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin:/usr/games:/sbin:/usr/sbin:/usr/local/bin/X11:/usr/local/bin/mh:/data/mysql/bin:/usr/local/bin/pbm:/usr/local/bin/ezmlm:/home/mjd/TPI/bin:/usr/local/teTeX/bin:/usr/local/mysql/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash


@p5pRT
Copy link
Author

p5pRT commented Jun 7, 2005

From @smpeters

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

A workaround is to write​:

    perl \-we '$file="X"; open my $fh\, "$file";'

The problem is that Perl sees the "my $fh, $file;" and assumes its a
list-like declaration using my which requires parens around the list.
This warning occurs with our as well.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

@p5pRT p5pRT closed this as completed Jun 7, 2005
@p5pRT
Copy link
Author

p5pRT commented Jun 7, 2005

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

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @mjdominus

Steve Peters​:

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

I don't think it is appropriate for you to be marking bugs as
"RESOLVED" when they have not been resolved. What's the point of
having a bug tracking system if you close bugs that are still extant?

I am grateful for all the hard work you have done to clean up the open
tickets, but I think that yu may have temporarily lost sight of the
real purpose of this project.

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @ysth

On Wed, Jun 08, 2005 at 03​:37​:45AM -0400, Mark Jason Dominus wrote​:

Steve Peters​:

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

I don't think it is appropriate for you to be marking bugs as
"RESOLVED" when they have not been resolved. What's the point of
having a bug tracking system if you close bugs that are still extant?

I am grateful for all the hard work you have done to clean up the open
tickets, but I think that yu may have temporarily lost sight of the
real purpose of this project.

I have to say that if any one bug admin thinks a bug is resolved, they
*should* mark it so, and rely on anyone else who thinks otherwise
sending further email to reopen it.

Hmm. mjd's response doesn't seem to have reopened the ticket, though.
Why not?

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @smpeters

[ysth - Wed Jun 08 01​:08​:32 2005]​:

On Wed, Jun 08, 2005 at 03​:37​:45AM -0400, Mark Jason Dominus wrote​:

Steve Peters​:

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

I don't think it is appropriate for you to be marking bugs as
"RESOLVED" when they have not been resolved. What's the point of
having a bug tracking system if you close bugs that are still extant?

I am grateful for all the hard work you have done to clean up the open
tickets, but I think that yu may have temporarily lost sight of the
real purpose of this project.

I have to say that if any one bug admin thinks a bug is resolved, they
*should* mark it so, and rely on anyone else who thinks otherwise
sending further email to reopen it.

Hmm. mjd's response doesn't seem to have reopened the ticket, though.
Why not?

The system is set to not automatically re-open tickets. There were
issues with having emails automatically reopening tickets.

This ticket has been reopened, but I not really sure why? Can you explain?

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

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

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @smpeters

[stmpeters - Wed Jun 08 03​:58​:28 2005]​:

[ysth - Wed Jun 08 01​:08​:32 2005]​:

On Wed, Jun 08, 2005 at 03​:37​:45AM -0400, Mark Jason Dominus wrote​:

Steve Peters​:

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

I don't think it is appropriate for you to be marking bugs as
"RESOLVED" when they have not been resolved. What's the point of
having a bug tracking system if you close bugs that are still extant?

I am grateful for all the hard work you have done to clean up the open
tickets, but I think that yu may have temporarily lost sight of the
real purpose of this project.

I have to say that if any one bug admin thinks a bug is resolved, they
*should* mark it so, and rely on anyone else who thinks otherwise
sending further email to reopen it.

Hmm. mjd's response doesn't seem to have reopened the ticket, though.
Why not?

The system is set to not automatically re-open tickets. There were
issues with having emails automatically reopening tickets.

This ticket has been reopened, but I not really sure why? Can you explain?

Oops! I forgot to copy p5p on the reply. Can you give an explanation of why this warning is
inappropriate please?

Thanks!

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @rgs

Steve Peters via RT wrote​:

This ticket has been reopened, but I not really sure why? Can you explain?

Oops! I forgot to copy p5p on the reply. Can you give an explanation of why this warning is
inappropriate please?

because the code is appropriately parsed by perl.

This is one of the heuristic warnings given by analysis of the textual input.
Note that C<open my $f, $file or die> doesn't warn, for example. And since
it's an heuristic, it's not trivial to fix ;)

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @Tux

On Wed, 8 Jun 2005 14​:19​:39 +0200, Rafael Garcia-Suarez
<rgarciasuarez@​mandriva.com> wrote​:

Steve Peters via RT wrote​:

This ticket has been reopened, but I not really sure why? Can you
explain?

Oops! I forgot to copy p5p on the reply. Can you give an explanation of
why this warning is inappropriate please?

because the code is appropriately parsed by perl.

This is one of the heuristic warnings given by analysis of the textual
input. Note that C<open my $f, $file or die> doesn't warn, for example. And
since it's an heuristic, it's not trivial to fix ;)

another rather annoying one is

pc09​:/home/merijn 101 > perl -we'$x="foo\nbar";-f $x and die "file"'
Unsuccessful stat on filename containing newline at -e line 1.
pc09​:/home/merijn 102 >

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http​://www.cmve.net/~merijn
Smoking perl​: http​://www.test-smoke.org, perl QA​: http​://qa.perl.org
reports to​: smokers-reports@​perl.org, perl-qa@​perl.org

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @smpeters

On Wed, Jun 08, 2005 at 02​:19​:39PM +0200, Rafael Garcia-Suarez wrote​:

Steve Peters via RT wrote​:

This ticket has been reopened, but I not really sure why? Can you explain?

Oops! I forgot to copy p5p on the reply. Can you give an explanation of why this warning is
inappropriate please?

because the code is appropriately parsed by perl.

This is one of the heuristic warnings given by analysis of the textual input.
Note that C<open my $f, $file or die> doesn't warn, for example. And since
it's an heuristic, it's not trivial to fix ;)

Right. After a quick glance at the code shows that creates the warning (
Perl_localize() in op.c), it looks like the warning is created when "my"
followed by a list not closed by parens and ends with a ";" or "=" cause the
warning. If it also generated the warning when the list is followed by
another keyword, I'd be much happier.

Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?

Steve Peters

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @rgs

Steve Peters wrote​:

Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?

No, I think it's still very useful for code like :

  my $foo, bar;

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @smpeters

[rgarciasuarez@​mandriva.com - Wed Jun 08 06​:18​:40 2005]​:

Steve Peters wrote​:

Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?

No, I think it's still very useful for code like :

my $foo\, bar;

In that case, though, a couple different warnings catch it.

perl -wle'my $foo, $bar;'
Parentheses missing around "my" list at -e line 1.
Useless use of a variable in void context at -e line 1.
Name "main​::bar" used only once​: possible typo at -e line 1.

with strict, it is caught ...

perl -Mstrict -wle'my $foo, $bar;'
Parentheses missing around "my" list at -e line 1.
Global symbol "$bar" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

while letting through cases where Perl and strict see it is appropriate.

perl -Mstrict -wle'my $file = "X"; open my $fh, $file;'
Parentheses missing around "my" list at -e line 1.

when assigned with a list without strict, it does seem to DWIM

perl -wle'my $foo, $bar = qw(foo bar); print $bar'
Parentheses missing around "my" list at -e line 1.
Useless use of a constant in void context at -e line 1.
bar

So, here's my suggestion. The warning should only be generated when
not using strict, since strict is a bit more specific on the problem. If
not using strict, then the warning should be generated only if strict
would be unhappy with it. Does this make sense?

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From gtwilliams@gmail.com

On Tue, 2005-06-07 at 23​:04 +0000, Steve Peters via RT wrote​:

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

A workaround is to write​:

    perl \-we '$file="X"; open my $fh\, "$file";'

The problem is that Perl sees the "my $fh, $file;" and assumes its a
list-like declaration using my which requires parens around the list.
This warning occurs with our as well.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

There's another "work-around"​:

  $ perl -we '$file="X"; open my $fh, $file;'
  Parentheses missing around "my" list at -e line 1.
  $ perl -we '$file="X"; open(my $fh, $file);'
  $ perl -v
 
  This is perl, v5.8.6 built for sun4-solaris

This looks "inappropriate" to me.

--
Garry Williams -- +1 (678) 656-4579

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @Abigail

On Wed, Jun 08, 2005 at 07​:06​:07AM -0400, Garry Williams wrote​:

On Tue, 2005-06-07 at 23​:04 +0000, Steve Peters via RT wrote​:

    perl \-we '$file="X"; open my $fh\, $file;'

            Parentheses missing around "my" list at \-e line 1\.

The warning is inappropriate in this context.

A workaround is to write​:

    perl \-we '$file="X"; open my $fh\, "$file";'

The problem is that Perl sees the "my $fh, $file;" and assumes its a
list-like declaration using my which requires parens around the list.
This warning occurs with our as well.

This can be prevented by simply putting a "()" around the $fh so that
Perl scopes the my correctly.

There's another "work-around"​:

    $ perl \-we '$file="X"; open my $fh\, $file;'
    Parentheses missing around "my" list at \-e line 1\.
    $ perl \-we '$file="X"; open\(my $fh\, $file\);'
    $ perl \-v
    
    This is perl\, v5\.8\.6 built for sun4\-solaris

This looks "inappropriate" to me.

  $ perl -we '$file="X"; open my $fh => $file;'
  $

Yet another reason to use '=>' instead of a comma. ;-)

Abigail

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2005

From @Abigail

On Wed, Jun 08, 2005 at 01​:41​:12PM -0000, Steve Peters via RT wrote​:

[rgarciasuarez@​mandriva.com - Wed Jun 08 06​:18​:40 2005]​:

Steve Peters wrote​:

Since the heuristics of this warning seem to be too simplistic for the
situation its trying to handle, is this warning needed?

No, I think it's still very useful for code like :

my $foo\, bar;

In that case, though, a couple different warnings catch it.

perl -wle'my $foo, $bar;'
Parentheses missing around "my" list at -e line 1.
Useless use of a variable in void context at -e line 1.
Name "main​::bar" used only once​: possible typo at -e line 1.

with strict, it is caught ...

perl -Mstrict -wle'my $foo, $bar;'
Parentheses missing around "my" list at -e line 1.
Global symbol "$bar" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

while letting through cases where Perl and strict see it is appropriate.

perl -Mstrict -wle'my $file = "X"; open my $fh, $file;'
Parentheses missing around "my" list at -e line 1.

when assigned with a list without strict, it does seem to DWIM

perl -wle'my $foo, $bar = qw(foo bar); print $bar'
Parentheses missing around "my" list at -e line 1.
Useless use of a constant in void context at -e line 1.
bar

So, here's my suggestion. The warning should only be generated when
not using strict, since strict is a bit more specific on the problem. If
not using strict, then the warning should be generated only if strict
would be unhappy with it. Does this make sense?

It makes sense, but I disagree. One-liners aren't the programs you
really want warnings to have anyway.

In larger programs, you might write​:

  use strict;

  my $bar = ...;

  sub quux {
  my $foo, $bar = @​_;
  ...
  }

'strict' isn't going to complain here, because every variable is
defined. But you probably don't want to assign to the outer '$bar',
but have a lexical inner '$bar'.

Abigail

@p5pRT
Copy link
Author

p5pRT commented Mar 15, 2007

From yuki-o@is.naist.jp

This is a bug report for perl from yuki-o@​is.naist.jp,
generated with the help of perlbug 1.35 running under perl v5.8.8.

Greetings,

I found a bug on warnings.pm (v1.05). This related to the "parenthesis"
category, and Perl builtin function "open". Under Perl 5.6 or later,
"open" can have 3 arguments, and the first one can be a lexical variable.
If other two arguments are also lexical variables (not literal),
warnings.pm produce alerts wrongly​:

  Parentheses missing around "my" list at test.pl line 10.

If at least one variable is literal, warning does not occur. Predeclared
filehandle or "no warnings qw( parenthesis )" dismissed warnings. Below is
the test.pl​:

  #!/usr/bin/perl

  use 5.006;
  use strict;
  use warnings;

  my $mode = '<';
  my $file = 'file';

  open my $fh, $mode, $file; # not ok
  open my $fh, '<', $file; # ok
  open my $fh, $mode, 'file'; # ok

  my $fh;
  open $fh, $mode, $file; # ok

  no warnings qw( parenthesis );
  open my $fh, $mode, $file; # ok

Regards,


Flags​:
  category=library
  severity=medium


Site configuration information for perl v5.8.8​:

Configured by SYSTEM at Tue Jan 23 15​:57​:26 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration​:
  Platform​:
  osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
  uname=''
  config_args='undef'
  hint=recommended, useposix=true, d_sigaction=undef
  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='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-DUSE_PERLIO -DPERL_MSVCRT_READFIX',
  optimize='-MD -Zi -DNDEBUG -O1',
  cppflags='-DWIN32'
  ccversion='12.00.8804', gccversion='', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='link', ldflags ='-nologo -nodefaultlib -debug -opt​:ref,icf
-libpath​:"C​:\usr\lib\CORE" -machine​:x86'
  libpth=\lib
  libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
  perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
  libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-opt​:ref,icf -libpath​:"C​:\usr\lib\CORE" -machine​:x86'

Locally applied patches​:
  ACTIVEPERL_LOCAL_PATCHES_ENTRY
  Iin_load_module moved for compatibility with build 806
  Avoid signal flag SA_RESTART for older versions of HP-UX
  PerlEx support in CGI​::Carp
  Less verbose ExtUtils​::Install and Pod​::Find
  Patch for CAN-2005-0448 from Debian with modifications
  Rearrange @​INC so that 'site' is searched before 'perl'
  Partly reverted 24733 to preserve binary compatibility
  29930 win32.c typo in #define MULTIPLICITY
  29868 win32_async_check() can still loop indefinitely
  29690,29732 ANSIfy the PATH environment variable on Windows
  29689 Add error handling to win32_ansipath
  29675 Use short pathnames in $^X and @​INC
  29607,29676 allow blib.pm to be used for testing Win32 module
  29605 Implement killpg() for MSWin32
  29598 cwd() to return the short pathname
  29597 let readdir() return the alternate filename
  29590 Don't destroy the Unicode system environment on Perl startup
  29528 get ext/Win32/Win32.xs to compile on cygwin
  29509,29510,29511 Move Win32​::* functions into Win32 module
  29483 Move Win32 from win32/ext/Win32 to ext/Win32
  29481 Makefile.PL changes to compile Win32.xs using cygwin
  28671 Define PERL_NO_DEV_RANDOM on Windows
  28376 Add error checks after execing PL_cshname or PL_sh_path
  28305 Pod​::Html should not convert \"foo\" into ``foo''
  27833 Change anchor generation in Pod​::Html for '=item item 2'
  27832,27847 fix Pod​::Html​::depod() for multi-line strings
  27736 Make perl_fini() run with Sun WorkShop compiler
  27719 Document the functions htmlify() and anchorify() in Pod​::Html
  27619 Bug in Term​::ReadKey being triggered by a bug in Term​::ReadLine
  27549 Move DynaLoader.o into libperl.so
  27528 win32_pclose() error exit doesn't unlock mutex
  27527 win32_async_check() can loop indefinitely
  27515 ignore directories when searching @​INC
  27359 Fix -d​:Foo=bar syntax
  27210 Fix quote typo in c2ph
  27203 Allow compiling swigged C++ code
  27200 Make stat() on Windows handle trailing slashes correctly
  27194 Get perl_fini() running on HP-UX again
  27133 Initialise lastparen in the regexp structure
  27061 L<PerlIO> and Pod​::Html
  27034 Avoid \"Prototype mismatch\" warnings with autouse
  26970 Make Passive mode the default for Net​::FTP
  26921 Avoid getprotobyname/number calls in IO​::Socket​::INET
  26897,26903 Make common IPPROTO_* constants always available
  26670 Make '-s' on the shebang line parse -foo=bar switches
  26637 Make Borland and MinGW happy with change 26379
  26536 INSTALLSCRIPT versus INSTALLDIRS
  26379 Fix alarm() for Windows 2003
  26087 Storable 0.1 compatibility
  25861 IO​::File performace issue
  25084 long groups entry could cause memory exhaustion
  24699 ICMP_UNREACHABLE handling in Net​::Ping


@​INC for perl v5.8.8​:
  C​:/usr/site/lib
  C​:/usr/lib
  .


Environment for perl v5.8.8​:
  HOME (unset)
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=C​:\usr\site\bin;C​:\usr\bin;C​:\Perl\bin\;c​:\program
files\imagemagick-6.2.4-q16;C​:\WINDOWS\system32;C​:\WINDOWS;C​:\WINDOWS\System32\Wbem;C​:\Program
Files\QuickTime\QTSystem\;C​:\Program Files\cvsnt;C​:\Program
Files\Subversion\bin;C​:\Program Files\Java\jdk1.5.0_09\bin;C​:\Documents
and Settings\ohmae\My Documents\Program Files\jacobe.win32;C​:\Documents
and Settings\ohmae\My Documents\Program Files\tidy-060405-exe;C​:\Documents
and Settings\ohmae\My Documents\Program
Files\csstidy-exe-1.2;C​:\Perl\site\bin
  PERL_BADLANG (unset)
  SHELL (unset)

--
�$BBgA0�(B �$BM&51�(B (OHMAE Yuki)
Systems Biology Lab, Nara Institute of Science and Technology

@p5pRT
Copy link
Author

p5pRT commented Mar 15, 2007

From @rgarcia

On 15/03/07, via RT OHMAE Yuki <perlbug-followup@​perl.org> wrote​:

I found a bug on warnings.pm (v1.05). This related to the "parenthesis"
category, and Perl builtin function "open". Under Perl 5.6 or later,
"open" can have 3 arguments, and the first one can be a lexical variable.
If other two arguments are also lexical variables (not literal),
warnings.pm produce alerts wrongly​:

 Parentheses missing around "my" list at test\.pl line 10\.

Yes, this bug is known. It's due to the heuristics implemented in the
parser to find out if this warning should be generated or not. I don't
know a good way to make it better. Basically the tokenizer looks until
the next ";". You'll notice, for example, that if you add an "or die"
after the open() call, the warning isn't produced anymore...

@p5pRT
Copy link
Author

p5pRT commented Mar 15, 2007

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

@p5pRT
Copy link
Author

p5pRT commented Mar 15, 2007

From @davidnicol

On 3/15/07, Rafael Garcia-Suarez <rgarciasuarez@​gmail.com> wrote​:

If other two arguments are also lexical variables (not literal),
warnings.pm produce alerts wrongly​:

 Parentheses missing around "my" list at test\.pl line 10\.

Yes, this bug is known. It's due to the heuristics implemented in the
parser to find out if this warning should be generated or not. I don't
know a good way to make it better. Basically the tokenizer looks until
the next ";". You'll notice, for example, that if you add an "or die"
after the open() call, the warning isn't produced anymore...

As usual I don't know how realistic my suggestion is,
but this seems like a member of a growing class of
annoying gotchas that would all go away if, instead of
scope declarations getting taken care of in-line, with special
cases for all the places where special cases are required,
scope declarations (my, our) were to be handled in their own early
pass. (which could also take care of the situation of a long string
of blocks with the same variable names myed into each going
quadratic.)

Sometimes my is greedy, sometimes not; sometimes my wrongly
occurs within an implied scope (which is considered a bug); and
the logic for figuring out what my applies to has to be duplicated
to implement diagnostics, which are sometimes wrong.

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

1 participant