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

(($x = 3) == ($x = 4)) evaluates to 1 #466

Closed
p5pRT opened this issue Sep 1, 1999 · 5 comments
Closed

(($x = 3) == ($x = 4)) evaluates to 1 #466

p5pRT opened this issue Sep 1, 1999 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 1, 1999

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

Searchable as RT1307$

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 1999

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.

Perl Info


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

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 1999

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

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 1999

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>

@p5pRT
Copy link
Author

p5pRT commented Sep 3, 1999

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

@p5pRT
Copy link
Author

p5pRT commented Sep 3, 1999

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

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