From lucs@CAM.ORG

If the value of the expression ($x = 3) is 3, and that of ($x = 4) is
4, why does (($x = 3) == ($x = 4)) evaluate to 1 instead of 0? Such
code probably rarely occurs, but the following (simplified compared to
what was in the program) sort expression manifests the same (?) problem,
in a perhaps less obvious way​:

  ($a =~ m/(\d)/ ? $1 : 0) <=> ($b =~ m/(\d)/ ? $1 : 0)

I suspect that optimizations are at work, but found nothing in the
docs.

Site configuration information for perl 5.00502:

Configured by root at Thu Oct 15 23:56:30 /etc/localtime 1998.

Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
  Platform:
    osname=linux, osvers=2.0.34, archname=i586-linux
    uname='linux haydn 2.0.34 #2 sun jun 28 16:29:40 etclocaltime 1998 i586 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.7.2.3
    cppflags='-Dbool=char -DHAS_BOOL'
    ccflags ='-Dbool=char -DHAS_BOOL'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    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
    libc=, 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 5.00502:
    /usr/lib/perl5/5.00502/i586-linux
    /usr/lib/perl5/5.00502
    /usr/lib/perl5/site_perl/5.005/i586-linux
    /usr/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00502:
    HOME=/home/lucs
    LANG (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/home/lucs/local/bin:/usr/local/teTeX/bin:/opt/postgres/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @tamias

On Wed, Sep 01, 1999 at 01​:33​:40PM -0400, Luc St-Louis wrote​:

this is a bug report for perl from lucs@​cam.org
generated with the help of perlbug 1.26 running under perl 5.00502.

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

If the value of the expression ($x = 3) is 3, and that of ($x = 4) is
4, why does (($x = 3) == ($x = 4)) evaluate to 1 instead of 0? Such
code probably rarely occurs, but the following (simplified compared to
what was in the program) sort expression manifests the same (?) problem,
in a perhaps less obvious way​:

($a =~ m/(\d)/ ? $1 : 0) <=> ($b =~ m/(\d)/ ? $1 : 0)

I suspect that optimizations are at work, but found nothing in the
docs.

I would say that this is for the same reason that

($x = 1, ++$x, ++$x)

returns the list (3, 3, 3).

($x = 3) assigns 3 to $x, and pushes a reference to $x on the stack.
($x = 4) assigns 4 to $x, and pushes a reference to $x on the stack.

(($x = 3) == ($x = 4)) pops both references to $x from the stack, and
dereferences them, so that both references result in the same value.

Ronald

From [Unknown Contact. See original ticket]

On Wed, 01 Sep 1999 at 17​:42​:24 -0400, Ronald J Kimball wrote​:

On Wed, Sep 01, 1999 at 01​:33​:40PM -0400, Luc St-Louis wrote​:

[Please enter your report here]

If the value of the expression ($x = 3) is 3, and that of ($x = 4) is
4, why does (($x = 3) == ($x = 4)) evaluate to 1 instead of 0? Such

Side-effects, as explained by Ronald.

code probably rarely occurs, but the following (simplified compared to
what was in the program) sort expression manifests the same (?) problem,
in a perhaps less obvious way​:

($a =~ m/(\d)/ ? $1 : 0) <=> ($b =~ m/(\d)/ ? $1 : 0)

I assume that this is the code you're really interested in, and there
does appear to be a bug - although there's an implicit assignment to $1,
I should have expected its up-to-date result to be available in each
sub-expression, since the result of the conditional can't be held simply
as a reference to $1.

This works around the problem​: (Note that I've changed the REs a little,
since yours won't do a very good sort)

sort { (my $junk = $a =~ m/(\d+)/ ? $1 : 0) <=> ($b =~ m/(\d+)/ ? $1 : 0) }

Just making Perl save the first sub-expression is enough to fix it.

Ian
--
  I am confident this explanation will dispell any feelings
  of certainty that may have been troubling you.
  - BWHOLMES@​SJSUVM1.sjsu.edu (Cabbage) in <9601221753.AA27669@​spock>

From [Unknown Contact. See original ticket]

Luc St-Louis <lucs@​CAM.ORG> writes​:

this is a bug report for perl from lucs@​cam.org
generated with the help of perlbug 1.26 running under perl 5.00502.

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

If the value of the expression ($x = 3) is 3, and that of ($x = 4) is
4, why does (($x = 3) == ($x = 4)) evaluate to 1 instead of 0?

Because $x == $x.

--
Nick Ing-Simmons

From [Unknown Contact. See original ticket]

Ian Phillipps <ian@​dial.pipex.com> wrote

I assume that this is the code you're really interested in, and there
does appear to be a bug - although there's an implicit assignment to $1,
I should have expected its up-to-date result to be available in each
sub-expression, since the result of the conditional can't be held simply
as a reference to $1.

  [ Just guessing, without looking at the Perl source ... ]

I'd quite expect it to be so held. Remember that a conditional can
be used as the LHS of an assignment, so unless there are different OPs
for the lvalue and rvalue cases, that'd be the obvious thing to do.

Mike Guy