Probably not a bug, still suspect

[p5pRT]

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

Searchable as RT5888$

[p5pRT]

From me-01@ton.iguana.be

perl -wle 'use Data​::Dumper; my $nn=0; print Dumper({index=> $nn\,offset=> ++$nn})'

prints

$VAR1 = {   'offset' => 1\,   'index' => 1   };

perl -wle 'use Data​::Dumper; my $nn=0; print Dumper({index=> $nn+0\,offset=> ++$nn})'

$VAR1 = {   'offset' => '1'\,   'index' => '0'   };

Now\, I know this is strictly speaking not a bug. Perl is like C in this respect\, and I should not have depended on the order in which sideeffects are done.

Having said that\, I always understood that perl basically executes it's ops in the order they are given\, so I would have expected (1\,0) in both cases\, so I was in fact surprised by the output.

I mention it in a bugreport because someone understanding optrees should maybe have a quick think if this is indeed ok.

If it is ok\, you can use it as a warning example in the docs to be wary of side effects :-)

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.6.0: Configured by ton at Wed Aug 9 23:24:07 CEST 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.4.0-test5, archname=i686-linux uname='linux quasar 2.4.0-test5 #2 sat jul 29 04:45:14 cest 2000 i686 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-O2 -fomit-frame-pointer', gccversion=egcs-2.91.66 19990314 (egcs-1.1.2 release), gccosandvers= cppflags='-fno-strict-aliasing -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include' 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 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=y, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib -L/opt/gnu/lib' libpth=/usr/local/lib /opt/gnu/lib /lib /usr/lib libs=-lnsl -lndbm -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.1.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.6.0/i686-linux/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib -L/opt/gnu/lib' Locally applied patches: @INC for perl v5.6.0: /usr/lib/perl5/5.6.0/i686-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i686-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl . Environment for perl v5.6.0: HOME=/home/ton LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/ton/bin.Linux:/home/ton/bin:/home/ton/bin.SampleSetup:/usr/local/bin:/usr/local/sbin:/usr/local/jre/bin:/usr/local/jdk116_v5/bin:/home/oracle/product/8.1.5/bin:/usr/games/bin:/usr/X11R6/bin:/usr/share/bin:/usr/bin:/usr/sbin:/bin:/sbin:. PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From [Unknown Contact. See original ticket]

In article \20010222055925\.20776\.qmail@​quasar\.home\.lunix\,   me-01@​ton.iguana.be writes​:

This is a bug report for perl from thospel@​mail.dma.be\, generated with the help of perlbug 1.31 running under perl v5.6.0.

Ok\, so I took a look at the optree myself. Absolutely no bug here\, move on\, no bugs here.

How do a close a bug report ?

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

perl -wle 'use Data​::Dumper; my $nn=0; print Dumper({index=> $nn\,offset=> ++$nn})'

prints

$VAR1 = { 'offset' => 1\, 'index' => 1 };

perl -wle 'use Data​::Dumper; my $nn=0; print Dumper({index=> $nn+0\,offset=> ++$nn})'

$VAR1 = { 'offset' => '1'\, 'index' => '0' };

Now\, I know this is strictly speaking not a bug. Perl is like C in this respect\, and I should not have depended on the order in which sideeffects are done.

Having said that\, I always understood that perl basically executes it's ops in the order they are given\, so I would have expected (1\,0) in both cases\, so I was in fact surprised by the output.

I mention it in a bugreport because someone understanding optrees should maybe have a quick think if this is indeed ok.

[p5pRT]

From @pudge

At 06​:27 +0000 2001.02.22\, Ton Hospel wrote​:

Ok\, so I took a look at the optree myself. Absolutely no bug here\, move on\, no bugs here.

How do a close a bug report ?

Do we have a volunteer to be a bug admin person? :) Richard Foley handles all that. Should be accessible at richard@​perl.org.