From @epa

Created by @epa

perl -we 'not $_'
generates a warning, correctly.

perl -we 'not 1'
gives no warning. It should.

Flags:
    category=core
    severity=low

This perlbug was built using Perl 5.10.0 in the Fedora build system.
It is being executed now by Perl 5.10.0 - Mon Jul 20 21:01:19 BST 2009.

Site configuration information for perl 5.10.0:

Configured by Red Hat, Inc. at Mon Jul 20 21:01:19 BST 2009.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.29.4-167.fc11.i586, archname=i386-linux-thread-multi
    uname='linux linux01 2.6.29.4-167.fc11.i586 #1 smp wed may 27 17:14:37 edt 2009 i686 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -Accflags=-DPERL_USE_SAFE_PUTENV -Dversion=5.10.0 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dprivlib=/usr/lib/perl5/5.10.0 -Dsitelib=/usr/local/lib/perl5/site_perl/5.10.0 -Dvendorlib=/usr/lib/perl5/vendor_perl/5.10.0 -Darchlib=/usr/lib/perl5/5.10.0/i386-linux-thread-multi -Dsitearch=/usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi -Dvendorarch=/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi -Dinc_version_list=none -Darchname=i386-linux-thread-multi -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dotherlibdirs=/usr/lib/perl5/site_perl'
    hint=recommended, useposix=true, d_sigaction=define
    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='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='4.4.0 20090506 (Red Hat 4.4.0-4)', 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='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.10.1.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.10.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.10.0:
    /home/eda/lib/perl5/5.10.0/i386-linux-thread-multi
    /home/eda/lib/perl5/5.10.0
    /home/eda/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi
    /home/eda/lib/perl5/site_perl/5.10.0
    /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi
    /usr/local/lib/perl5/site_perl/5.10.0
    /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.10.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.10.0/i386-linux-thread-multi
    /usr/lib/perl5/5.10.0
    /usr/lib/perl5/site_perl/5.10.0
    /usr/lib/perl5/site_perl
    .


Environment for perl 5.10.0:
    HOME=/home/eda
    LANG=en_GB.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_CTYPE=en_GB.UTF-8
    LC_MESSAGES=en_GB.UTF-8
    LC_MONETARY=en_GB.UTF-8
    LC_NUMERIC=en_GB.UTF-8
    LC_TIME=en_GB.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/eda/bin:/home/eda/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/sbin:/usr/sbin
    PERL5LIB=/home/eda/lib/perl5/5.10.0:/home/eda/lib/perl5/site_perl/5.10.0
    PERL_BADLANG (unset)
    SHELL=/bin/bash

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

From @rgs

2009/8/17 Ed Avis <perlbug-followup@​perl.org>​:

perl -we 'not $_'
generates a warning, correctly.

perl -we 'not 1'
gives no warning.  It should.

That's constant-folded to 0, and the constants 0 (and 1) are
specifically excluded from this warning...

$ perl -we0
$ perl -we1
$ perl -we2
Useless use of a constant in void context at -e line 1.

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

From @ikegami

On Mon, Aug 17, 2009 at 1​:21 PM, Rafael Garcia-Suarez <
rgarciasuarez@​gmail.com> wrote​:

2009/8/17 Ed Avis <perlbug-followup@​perl.org>​:

perl -we 'not $_'
generates a warning, correctly.

perl -we 'not 1'
gives no warning. It should.

That's constant-folded to 0, and the constants 0 (and 1) are
specifically excluded from this warning...

$ perl -we0
$ perl -we1
$ perl -we2
Useless use of a constant in void context at -e line 1.

It's more than that​:

$ perl -we'not 3'

$

From @ikegami

On Mon, Aug 17, 2009 at 3​:07 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

On Mon, Aug 17, 2009 at 1​:21 PM, Rafael Garcia-Suarez <
rgarciasuarez@​gmail.com> wrote​:

2009/8/17 Ed Avis <perlbug-followup@​perl.org>​:

perl -we 'not $_'
generates a warning, correctly.

perl -we 'not 1'
gives no warning. It should.

That's constant-folded to 0, and the constants 0 (and 1) are
specifically excluded from this warning...

$ perl -we0
$ perl -we1
$ perl -we2
Useless use of a constant in void context at -e line 1.

It's more than that​:

$ perl -we'not 3'

$

Sorry, bad example. Here's a better one, but it uses "and" instead of "not"​:

$ perl -we'3 and 4'

$ perl -we'$_ and $_'
Useless use of a variable in void context at -e line 1.

$ perl -we'3'
Useless use of a constant in void context at -e line 1.

From ben@morrow.me.uk

Quoth ikegami@​adaelis.com (Eric Brine)​:

On Mon, Aug 17, 2009 at 3​:07 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

On Mon, Aug 17, 2009 at 1​:21 PM, Rafael Garcia-Suarez <
rgarciasuarez@​gmail.com> wrote​:

2009/8/17 Ed Avis <perlbug-followup@​perl.org>​:

perl -we 'not $_'
generates a warning, correctly.

perl -we 'not 1'
gives no warning. It should.

That's constant-folded to 0, and the constants 0 (and 1) are
specifically excluded from this warning...

$ perl -we0
$ perl -we1
$ perl -we2
Useless use of a constant in void context at -e line 1.

It's more than that​:

$ perl -we'not 3'

$

Sorry, bad example. Here's a better one, but it uses "and" instead of "not"​:

$ perl -we'3 and 4'

It's the same. '3 and 4' is constant-folded to 0 at compile time, and 0
doesn't warn.

Ben

From Eirik-Berg.Hanssen@allverden.no

Ben Morrow <ben@​morrow.me.uk> writes​:

Quoth ikegami@​adaelis.com (Eric Brine)​:

Sorry, bad example. Here's a better one, but it uses "and" instead of "not"​:

$ perl -we'3 and 4'

It's the same. '3 and 4' is constant-folded to 0 at compile time, and 0
doesn't warn.

  Funny, '3 and 4' is not constant-folded to 0 in non-void contexts ...

perl -le 'print(3 and 4); print 0+(3 and 4);'
4
4

  ;-)

Eirik
--
I knew I'd hate COBOL the moment I saw they'd used "perform" instead of "do".
  -- Larry Wall

From @Abigail

On Mon, Aug 17, 2009 at 10​:04​:20PM +0200, Eirik Berg Hanssen wrote​:

Ben Morrow <ben@​morrow.me.uk> writes​:

Quoth ikegami@​adaelis.com (Eric Brine)​:

Sorry, bad example. Here's a better one, but it uses "and" instead of "not"​:

$ perl -we'3 and 4'

It's the same. '3 and 4' is constant-folded to 0 at compile time, and 0
doesn't warn.

Funny, '3 and 4' is not constant-folded to 0 in non-void contexts ...

perl -le 'print(3 and 4); print 0+(3 and 4);'
4
4

;-)

  $ perl -MO=Deparse -wE '3 and 4; say (3 and 4)'
  say (...) interpreted as function at -e line 1.
  BEGIN { $^W = 1; }
  BEGIN {
  $^H{'feature_say'} = q(1);
  $^H{'feature_state'} = q(1);
  $^H{'feature_switch'} = q(1);
  }
  '???';
  say 4;
  -e syntax OK
  $

Abigail

From @ikegami

On Mon, Aug 17, 2009 at 3​:47 PM, Ben Morrow <ben@​morrow.me.uk> wrote​:

Quoth ikegami@​adaelis.com (Eric Brine)​:

Sorry, bad example. Here's a better one, but it uses "and" instead of
"not"​:

$ perl -we'3 and 4'

It's the same. '3 and 4' is constant-folded to 0 at compile time, and 0
doesn't warn.

No, it gets constant-folded to 4​:

$ perl -MO=Concise -e'3 and 4'
3 <@​> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e​:1) v ->3
- <0> ex-const v/4 ->3
-e syntax OK

Are you thinking of bitwise-and (3 & 4)?

From @ikegami

On Mon, Aug 17, 2009 at 5​:44 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

On Mon, Aug 17, 2009 at 3​:47 PM, Ben Morrow <ben@​morrow.me.uk> wrote​:

Quoth ikegami@​adaelis.com (Eric Brine)​:

Sorry, bad example. Here's a better one, but it uses "and" instead of
"not"​:

$ perl -we'3 and 4'

It's the same. '3 and 4' is constant-folded to 0 at compile time, and 0
doesn't warn.

No, it gets constant-folded to 4​:

$ perl -MO=Concise -e'3 and 4'
3 <@​> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e​:1) v ->3
- <0> ex-const v/4 ->3
-e syntax OK

Are you thinking of bitwise-and (3 & 4)?

Eric is apparently tired. It should have been constant-folded to 4, but it
doesn't show to what it was constant-folded. Why do you think it's being
constant-folded to zero?

From @davidnicol

Why do you think it's being
constant-folded to zero?

he thinks its being constant-folded to something that would
legitimately not trigger the warning. It's a bug. Patch it.

From ben@morrow.me.uk

Quoth ikegami@​adaelis.com (Eric Brine)​:

On Mon, Aug 17, 2009 at 5​:44 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

On Mon, Aug 17, 2009 at 3​:47 PM, Ben Morrow <ben@​morrow.me.uk> wrote​:

Quoth ikegami@​adaelis.com (Eric Brine)​:

Sorry, bad example. Here's a better one, but it uses "and" instead of
"not"​:

$ perl -we'3 and 4'

It's the same. '3 and 4' is constant-folded to 0 at compile time, and 0
doesn't warn.

No, it gets constant-folded to 4​:

$ perl -MO=Concise -e'3 and 4'
3 <@​> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e​:1) v ->3
- <0> ex-const v/4 ->3
-e syntax OK

Are you thinking of bitwise-and (3 & 4)?

Eric is apparently tired. It should have been constant-folded to 4, but it
doesn't show to what it was constant-folded. Why do you think it's being
constant-folded to zero?

It's me who's tired, not you. It gets constant-folded to 4, and then the
4 gets thrown away since it's in void context. Sorry for the confusion.

What happens next is it gets caught by this piece of code in op.c​:

  /* don't warn on optimised away booleans, eg
  * use constant Foo, 5; Foo || print; */
  if (cSVOPo->op_private & OPpCONST_SHORTCIRCUIT)
  useless = NULL;

as it seems that once constant-folding has taken place it is impossible
to distinguish

  3 or 4;

which should not warn from

  3 and 4;

which should. This is certainly a bug, though I'm not sure it's one
worth fixing.

Ben

From @Abigail

On Tue, Aug 18, 2009 at 12​:03​:42AM +0100, Ben Morrow wrote​:

It's me who's tired, not you. It gets constant-folded to 4, and then the
4 gets thrown away since it's in void context. Sorry for the confusion.

What happens next is it gets caught by this piece of code in op.c​:

/\* don't warn on optimised away booleans\, eg 
 \* use constant Foo\, 5; Foo || print; \*/

Here's the '5' isn't in void context - they only thing in void context
is the '||' operator.

if \(cSVOPo\->op\_private & OPpCONST\_SHORTCIRCUIT\)
    useless = NULL;

as it seems that once constant-folding has taken place it is impossible
to distinguish

3 or 4;

which should not warn from

3 and 4;

which should. This is certainly a bug, though I'm not sure it's one
worth fixing.

Eh, why should C<< 3 and 4; >> warn when C<< 3 or 4; >> shouldn't? I don't
have much opinion on whether C<< 3 and 4; >> and C<< 3 or 4; >> should
warn or not, but I do care about consistency. Either both of them should
warn, or neither. Just one of them doesn't make sense.

Abigail

From ben@morrow.me.uk

Quoth abigail@​abigail.be (Abigail)​:

On Tue, Aug 18, 2009 at 12​:03​:42AM +0100, Ben Morrow wrote​:

It's me who's tired, not you. It gets constant-folded to 4, and then the
4 gets thrown away since it's in void context. Sorry for the confusion.

What happens next is it gets caught by this piece of code in op.c​:

/\* don't warn on optimised away booleans\, eg 
 \* use constant Foo\, 5; Foo || print; \*/

Here's the '5' isn't in void context - they only thing in void context
is the '||' operator.

The whole 'Foo || print' expression gets optimized to '5' before we get
here; that '5' is then in void context, but marked _SHORTCIRCUIT. Since
the original expression didn't have a constant in void context, it's
important not to issue a warning.

if \(cSVOPo\->op\_private & OPpCONST\_SHORTCIRCUIT\)
    useless = NULL;

as it seems that once constant-folding has taken place it is impossible
to distinguish

3 or 4;

which should not warn from

3 and 4;

which should. This is certainly a bug, though I'm not sure it's one
worth fixing.

Eh, why should C<< 3 and 4; >> warn when C<< 3 or 4; >> shouldn't? I don't
have much opinion on whether C<< 3 and 4; >> and C<< 3 or 4; >> should
warn or not, but I do care about consistency. Either both of them should
warn, or neither. Just one of them doesn't make sense.

OK, '3 or 4' was a bad example. It's impossible to distinguish

  3 or print;

which absolutely should not warn from

  1 and 3;

which should, since both get optimized to just '3'. Probably the second
should *not* be marked _SHORTCIRCUIT, since the constant was in void
context to start with, but I wouldn't know where to start trying to fix
that.

Ben

From @davidnicol

On Mon, Aug 17, 2009 at 8​:11 PM, Ben Morrow<ben@​morrow.me.uk>

which should, since both get optimized to just '3'. Probably the second
should *not* be marked _SHORTCIRCUIT, since the constant was in void
context to start with, but I wouldn't know where to start trying to fix
that.

Ben

Trying to move warning generation before optimization rather than
after is too complex a notion to entertain seriously, right? One of
those things that would only make sense to do with a major
refactoring.

From gerard@ggoossen.net

On Tue, Aug 18, 2009 at 08​:41​:29AM -0500, David Nicol wrote​:

On Mon, Aug 17, 2009 at 8​:11 PM, Ben Morrow<ben@​morrow.me.uk>

which should, since both get optimized to just '3'. Probably the second
should *not* be marked _SHORTCIRCUIT, since the constant was in void
context to start with, but I wouldn't know where to start trying to fix
that.

Ben

Trying to move warning generation before optimization rather than
after is too complex a notion to entertain seriously, right? One of
those things that would only make sense to do with a major
refactoring.

My proposal to Changing the Perl 5 optree build process into an
Abstract Syntax Tree generation and a code generation
(see http​://news.perlfoundation.org/2009/08/2009q3_grant_proposal_changing.html)
would do that, and thus resolve these issues.

Gerard Goossen.