perllexwarn mentions EQ, but EQ is gone

[p5pRT]

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

Searchable as RT3898$

[p5pRT]

From @nwc10

Created by @nwc10

perllexwarn mentions EQ and NE; eg

  use warnings ;

  $a = 1 if $a EQ $b ;

  {   use warnings FATAL => qw(deprecated) ;   $a = 1 if $a EQ $b ;   }

  $a = 1 if $a EQ $b ;

yet when I run that with perl 5.7 I get​:

Bareword found where operator expected at bug56 line 3\, near "$a EQ"   (Missing operator before EQ?) syntax error at bug56 line 3\, near "$a EQ " BEGIN not safe after errors--compilation aborted at bug56 line 6.

because EQ\, NE and friends have been removed. I was going to provide a patched replacement involving split in a void context and $# (two things which make depreciated warnings) but as the above construction isn't FATAL in 5.6 I wasn't sure I would be able to test it.

Nicholas Clark

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl v5.7.0: Configured by nick at Sun Aug 27 17:26:14 BST 2000. Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration: Platform: osname=linux, osvers=2.2.16-rmk2, archname=armv4l-linux uname='linux bagpuss.unfortu.net 2.2.16-rmk2 #8 thu jul 20 12:24:36 bst 2000 armv4l unknown ' config_args='' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-g', gccversion=2.95.2 20000220 (Debian GNU/Linux), gccosandvers= cppflags='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 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=-lsfio -lnsl -lndbm -ldb -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: SUIDMAIL - fixes for suidperl security DEVEL6849 @INC for perl v5.7.0: /usr/local/lib/perl5/5.7.0/armv4l-linux /usr/local/lib/perl5/5.7.0 /usr/local/lib/perl5/site_perl/5.7.0/armv4l-linux /usr/local/lib/perl5/site_perl/5.7.0 /usr/local/lib/perl5/site_perl . Environment for perl v5.7.0: HOME=/home/nick LANG (unset) LANGUAGE (unset) LC_CTYPE=en_GB.ISO-8859-1 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/nick/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/sbin:/usr/sbin:/usr/local/sbin PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From [Unknown Contact. See original ticket]

Nicholas Clark wrote​:

I was going to provide a patched replacement involving split in a void context and $# (two things which make depreciated warnings) but as the above construction isn't FATAL in 5.6 I wasn't sure I would be able to test it.

Would it not make more sense to pick a category other than "deprecated" to reduce the possibility of needing to do this again? My vote would be for "syntax". One example​:

  use warnings FATAL => qw(syntax);   $s = @​a[0];

[p5pRT]

From [Unknown Contact. See original ticket]

Lightning flashed\, thunder crashed and Rick Delaney \rick\.delaney@​home\.com whi spered​:	Would it not make more sense to pick a category other than "deprecated"	to reduce the possibility of needing to do this again? My vote would be	for "syntax". One example​:
use warnings FATAL => qw(syntax);
$s = @​a[0];

I'm not sure this particular example is any less likely to change than a deprecated feature. Someone might come along one day and decide to clean that up as well.

I've wondered from time to time how long we have to keep deprecated features around\, and whether we can start making certain deprecated syntax (like the above) be fatal errors by default.

Would a mask error (variable %s masks earlier declaration in same %s) be a better choice?

-spp

[p5pRT]

From @ysth

In article \200008281544\.LAA20394@​spp\.users\.ds\.net\, "Stephen P. Potter" \spp@​ds\.net wrote​:

Lightning flashed\, thunder crashed and Rick Delaney \rick\.delaney@​home\.com whi spered​:	Would it not make more sense to pick a category other than "deprecated"	to reduce the possibility of needing to do this again? My vote would be	for "syntax". One example​:
use warnings FATAL => qw(syntax);
$s = @​a[0];

I'm not sure this particular example is any less likely to change than a deprecated feature. Someone might come along one day and decide to clean that up as well.

What do you mean clean it up? It's perfectly valid syntax. The only reason for the warning is that the coder is likely to be a novice who needs to be told how to access array elements in Perl. This is a good enough reason for the warning\, but certainly not a good enough reason to outlaw array slices with hardcoded single indices.

[p5pRT]

From @pmqs

From​: Nick Clark [mailto​:nick@​plum.flirble.org]On Behalf Of Nicholas

This is a bug report for perl from nick@​talking.bollo.cx\, generated with the help of perlbug 1.32 running under perl v5.7.0.

----------------------------------------------------------------- [Please enter your report here]

perllexwarn mentions EQ and NE; eg

       use warnings ;

       $a = 1 if $a EQ $b ;

       \{
           use warnings FATAL => qw\(deprecated\) ;
           $a = 1 if $a EQ $b ;
       \}

       $a = 1 if $a EQ $b ;

yet when I run that with perl 5.7 I get​:

Bareword found where operator expected at bug56 line 3\, near "$a EQ" (Missing operator before EQ?) syntax error at bug56 line 3\, near "$a EQ " BEGIN not safe after errors--compilation aborted at bug56 line 6.

because EQ\, NE and friends have been removed. I was going to provide a patched replacement involving split in a void context and $# (two things which make depreciated warnings) but as the above construction isn't FATAL in 5.6 I wasn't sure I would be able to test it.

Thanks\, I'll provide a patch that uses a more sensible warning as a example.

Paul

__________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http​://im.yahoo.com

[p5pRT]

From @pmqs

From​: Rick Delaney [mailto​:rick.delaney@​home.com]

Nicholas Clark wrote​:

I was going to provide a patched replacement involving split in a void context and $# (two things which make depreciated warnings) but as the above construction isn't FATAL in 5.6 I wasn't sure I would be able to test it.

Would it not make more sense to pick a category other than "deprecated" to reduce the possibility of needing to do this again? My vote would be for "syntax". One example​:

use warnings FATAL => qw\(syntax\);
$s = @​a\[0\];

Yep\, I really shouldn't have picked "deprecated" as an example to demonstrate how lexical warnings worked. I'll change the examples.

Paul

__________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http​://im.yahoo.com

[p5pRT]

From [Unknown Contact. See original ticket]

Lightning flashed\, thunder crashed and sthoenna@​efn.org (Yitzchak Scott-Thoenne s) whispered​: | What do you mean clean it up? It's perfectly valid syntax. The only | reason for the warning is that the coder is likely to be a novice who | needs to be told how to access array elements in Perl. This is a good | enough reason for the warning\, but certainly not a good enough reason | to outlaw array slices with hardcoded single indices.

I might question whether it should be valid syntax to have a slice that is only a single element in a place that is looking for a scalar. Note\, I'm not suggesting it is wrong or should be changed. But\, someone could make a case that if it needs a warning like that\, it should be considered an error and changed.

-spp

[p5pRT]

From @mjdominus

I might question whether it should be valid syntax to have a slice that is only a single element in a place that is looking for a scalar. Note\, I'm not suggesting it is wrong or should be changed. But\, someone could make a case that if it needs a warning like that\, it should be considered an error and changed.

I will make the counter-case​: I have a program that contains

  my @​s = (&senders()\, &forwarders()\, @​H{'Reply-to'});

If I had written $H{'Reply-To'} here\, my program would have had a bug.

[p5pRT]

From @tamias

On Mon\, Aug 28\, 2000 at 04​:20​:15PM -0400\, Mark-Jason Dominus wrote​:

I might question whether it should be valid syntax to have a slice that is only a single element in a place that is looking for a scalar. Note\, I'm not suggesting it is wrong or should be changed. But\, someone could make a case that if it needs a warning like that\, it should be considered an error and changed.

I will make the counter-case​: I have a program that contains

      my @​s = \(&senders\(\)\, &forwarders\(\)\, @​H\{'Reply\-to'\}\);

If I had written $H{'Reply-To'} here\, my program would have had a bug.

I don't grasp the difference. As far as I can tell both forms evaluate to undef() when $H{'Reply-to'} doesn't exist.

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

I will make the counter-case​: I have a program that contains

      my @​s = \(&senders\(\)\, &forwarders\(\)\, @​H\{'Reply\-to'\}\);

If I had written $H{'Reply-To'} here\, my program would have had a bug.

I don't grasp the difference. As far as I can tell both forms evaluate to undef() when $H{'Reply-to'} doesn't exist.

@​H{'Reply-to'} does not evaluate as undef. It evaluates as (); the null list.

perl -le '@​s=((1\,2)\,(3\,4)\,undef); print "to="\,join "\,to="\,@​s;' to=1\,to=2\,to=3\,to=4\,to= perl -le '@​s=((1\,2)\,(3\,4)\,()); print join "​:"\,@​s;' to=1\,to=2\,to=3\,to=4

[p5pRT]

From @mjdominus

@​H{'Reply-to'} does not evaluate as undef. It evaluates as (); the null list.

Are you sure? After Ronald asked me about it\, I tried it out\, and I wasn't able to get it to do that either.

I am really puzzled\, since I'm sure I tried it out at the time\, and I also remember a change not to long ago that had something to do with getting rid of a special case having to do with slices\, but on Friday I tried it out with versions back to 5.000 and they all seemed to do what Ronald said.

[p5pRT]

From @tamias

On Tue\, Aug 29\, 2000 at 01​:50​:57PM -0700\, Joe Smith wrote​:

I will make the counter-case​: I have a program that contains

      my @​s = \(&senders\(\)\, &forwarders\(\)\, @​H\{'Reply\-to'\}\);

If I had written $H{'Reply-To'} here\, my program would have had a bug.

I don't grasp the difference. As far as I can tell both forms evaluate to undef() when $H{'Reply-to'} doesn't exist.

@​H{'Reply-to'} does not evaluate as undef. It evaluates as (); the null list.

perl -le '@​s=((1\,2)\,(3\,4)\,undef); print "to="\,join "\,to="\,@​s;' to=1\,to=2\,to=3\,to=4\,to= perl -le '@​s=((1\,2)\,(3\,4)\,()); print join "​:"\,@​s;' to=1\,to=2\,to=3\,to=4

You are mistaken.

% perl -wle '%H=(); @​s = @​H{"Reply-to"}; print map "	$_	"\, @​s' Scalar value @​H{"Reply-to"} better written as $H{"Reply-to"} at -e line 1. Use of uninitialized value at -e line 1.

%

BTW\, what happened to the colons in your second example? :)

Ronald

[p5pRT]

From @abigail

On Tue\, Aug 29\, 2000 at 01​:50​:57PM -0700\, Joe Smith wrote​:

I will make the counter-case​: I have a program that contains

      my @​s = \(&senders\(\)\, &forwarders\(\)\, @​H\{'Reply\-to'\}\);

If I had written $H{'Reply-To'} here\, my program would have had a bug.

I don't grasp the difference. As far as I can tell both forms evaluate to undef() when $H{'Reply-to'} doesn't exist.

@​H{'Reply-to'} does not evaluate as undef. It evaluates as (); the null list.

perl -le '@​s=((1\,2)\,(3\,4)\,undef); print "to="\,join "\,to="\,@​s;' to=1\,to=2\,to=3\,to=4\,to= perl -le '@​s=((1\,2)\,(3\,4)\,()); print join "​:"\,@​s;' to=1\,to=2\,to=3\,to=4

The above code doesn't use @​H{'Reply-to'}\, so there's nothing to infer.

But​:

  $ perl -le '@​s = ((1\, 2)\, (3\, 4)\, @​H {"Reply-to"}); print scalar @​s'   5   $ perl -le '@​s = ((1\, 2)\, (3\, 4)\, ()); print scalar @​s'   4   $

So\, @​H {"Reply-to"} in list context doesn't evaluate to an empty list.

  $ perl -le '@​s = ((1\, 2)\, (3\, 4)\, @​H {"Reply-to"});   print "UNDEF" unless defined $s [-1]'   UNDEF

So\, it *is* undef.

Abigail

[p5pRT]

From @mjdominus

I am really puzzled\, since ... I also remember a change not to long ago that had something to do with getting rid of a special case having to do with slices\, ...

This is the special case I was thinking of\, and it doesn't apply here​:

  When taking a slice of a literal list (as opposed to a slice of   an array or hash)\, Perl used to return an empty list if the   result happened to be composed of all undef values.

(5.6 perldelta)

[p5pRT]

From [Unknown Contact. See original ticket]

I am really puzzled\, since I'm sure I tried it out at the time\, and I also remember a change not to long ago that had something to do with getting rid of a special case having to do with slices\, but on Friday I tried it out with versions back to 5.000 and they all seemed to do what Ronald said.

It had to do with a slice of a null list\, I believe.

--tom

[p5pRT]

From @nwc10

Fixed by change 6869 a long time ago.

http​://public.activestate.com/cgi-bin/perlbrowse?patch=6869

[p5pRT]

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