Swapping of $< and $> should be deprecated

[p5pRT]

Migrated from rt.perl.org#96212 (status was 'open')

Searchable as RT96212$

[p5pRT]

From @Leont

This is a bug report for perl from fawaka@​gmail.com,
generated with the help of perlbug 1.39 running under perl 5.14.1.

---

Perl has supported the idiom of swapping $&lt; and $&gt; (and likewise $( and $)) since 5.0. However, there are some issues with this.

* Most of al, it's useless. Unless you're running an early 90s BSD (that lacks a saved UID), there's no reason whatsoever to use this trick. You can just set $&gt; to $&lt; and then set it back to its previous value.
* It needlessly makes UID management and list assignment/nextstate more complicated (see also RT#96208).
* It may lead to subtle issues on some platforms in matters that depend on the real UID (such as signalling).

---

---

Flags​:
  category=core
  severity=low

---

Site configuration information for perl 5.14.1​:

Configured by leon at Tue Jun 28 15​:59​:52 CEST 2011.

Summary of my perl5 (revision 5 version 14 subversion 1) configuration​:
 
  Platform​:
  osname=linux, osvers=2.6.38-8-generic, archname=x86_64-linux
  uname='linux leon-laptop 2.6.38-8-generic #42-ubuntu smp mon apr 11 03​:31​:24 utc 2011 x86_64 x86_64 x86_64 gnulinux '
  config_args='-de -Dprefix=/home/leon/perl5/perlbrew/perls/perl-5.14.1'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2',
  cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.6.1 20110409 (prerelease)', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /usr/lib/x86_64-linux-gnu /lib64 /usr/lib64
  libs=-lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.13'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 

---

@​INC for perl 5.14.1​:
  /home/leon/perl5/perlbrew/perls/perl-5.14.1/lib/site_perl/5.14.1/x86_64-linux
  /home/leon/perl5/perlbrew/perls/perl-5.14.1/lib/site_perl/5.14.1
  /home/leon/perl5/perlbrew/perls/perl-5.14.1/lib/5.14.1/x86_64-linux
  /home/leon/perl5/perlbrew/perls/perl-5.14.1/lib/5.14.1
  .

---

Environment for perl 5.14.1​:
  HOME=/home/leon
  LANG=en_US.utf8
  LANGUAGE=en_US​:en
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/home/leon/perl5/perlbrew/bin​:/home/leon/perl5/perlbrew/perls/perl-5.14.1/bin​:/home/leon/bin​:/usr/local/sbin​:/usr/local/bin​:/usr/sbin​:/usr/bin​:/sbin​:/bin​:/usr/games
  PERLBREW_HOME=/home/leon/.perlbrew
  PERLBREW_PATH=/home/leon/perl5/perlbrew/bin​:/home/leon/perl5/perlbrew/perls/perl-5.14.1/bin
  PERLBREW_PERL=perl-5.14.1
  PERLBREW_ROOT=/home/leon/perl5/perlbrew
  PERLBREW_VERSION=0.25
  PERL_BADLANG (unset)
  SHELL=/bin/bash

[p5pRT]

From @cpansprout

On Wed Aug 03 08​:28​:45 2011, LeonT wrote​:

This is a bug report for perl from fawaka@​gmail.com,
generated with the help of perlbug 1.39 running under perl 5.14.1.

-----------------------------------------------------------------

Perl has supported the idiom of swapping $&lt; and $&gt; (and likewise $(
and $)) since 5.0. However, there are some issues with this.

* Most of al, it's useless. Unless you're running an early 90s BSD
(that lacks a saved UID), there's no reason whatsoever to use this
trick. You can just set $&gt; to $&lt; and then set it back to its
previous value.
* It needlessly makes UID management and list assignment/nextstate
more complicated (see also RT#96208).

Are you implying that the ability to swap $[<>] depends on the caching?

* It may lead to subtle issues on some platforms in matters that
depend on the real UID (such as signalling).

[p5pRT]

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

[p5pRT]

From @Leont

On Sat Oct 29 01​:12​:55 2011, sprout wrote​:

Are you implying that the ability to swap $[<>] depends on the caching?

In list assignment, assigning to $[<>] means setting the cache to the
new value. At the end of the list assignment, set(r|e|re|res|)uid is
called to set the actual property to the value in the cache.

Leon

[p5pRT]

From [Unknown Contact. See original ticket]

On Sat Oct 29 01​:12​:55 2011, sprout wrote​:

Are you implying that the ability to swap $[<>] depends on the caching?

In list assignment, assigning to $[<>] means setting the cache to the
new value. At the end of the list assignment, set(r|e|re|res|)uid is
called to set the actual property to the value in the cache.

Leon

[p5pRT]

From @Leont

On Wed, Aug 3, 2011 at 5​:28 PM, <fawaka@​gmail.com> wrote​:

Perl has supported the idiom of swapping $&lt; and $&gt; (and likewise $( and $)) since 5.0. However, there are some issues with this.

 * Most of al, it's useless. Unless you're running an early 90s BSD (that lacks a saved UID), there's no reason whatsoever to use this trick. You can just set $&gt; to $&lt; and then set it back to its previous value.
 * It needlessly makes UID management and list assignment/nextstate more complicated (see also RT#96208).
 * It may lead to subtle issues on some platforms in matters that depend on the real UID (such as signalling).

*Bump*

Can this be pre-deprecated in 5.16?

Leon

[p5pRT]

From @Leont

On Wed, Aug 3, 2011 at 5​:28 PM, Leon Timmermans
<perlbug-followup@​perl.org> wrote​:

Perl has supported the idiom of swapping $&lt; and $&gt; (and likewise $( and $)) since 5.0. However, there are some issues with this.

 * Most of al, it's useless. Unless you're running an early 90s BSD (that lacks a saved UID), there's no reason whatsoever to use this trick. You can just set $&gt; to $&lt; and then set it back to its previous value.
 * It needlessly makes UID management and list assignment/nextstate more complicated (see also RT#96208).
 * It may lead to subtle issues on some platforms in matters that depend on the real UID (such as signalling).

Can we deprecate or pre-deprecate this for 5.16? I'm not sure how to
interpret this warnocking…

Leon

[p5pRT]

From @doy

Pushed to doy/deprecate_uid_gid_swap. Didn't merge yet because the test
isn't really very accurate, it just checks for any of $&lt;, $&gt;, $(, or $)
being used on both the right and left side of a list assignment, but
would anyone be doing that outside of this context? Detecting an actual
swap would be pretty complicated.

-doy

[p5pRT]

From @Leont

On Tue, Jul 3, 2012 at 7​:15 PM, Jesse Luehrs via RT
<perlbug-followup@​perl.org> wrote​:

Pushed to doy/deprecate_uid_gid_swap. Didn't merge yet because the test
isn't really very accurate, it just checks for any of $&lt;, $&gt;, $(, or $)
being used on both the right and left side of a list assignment, but
would anyone be doing that outside of this context? Detecting an actual
swap would be pretty complicated.

Actually, it's easily and reliably detectable in runtime, pp_aasign
may be a better place to issue the warning, though maybe we'd want to
make sure it doesn't keep giving that warning.

Leon

[p5pRT]

From @doy

On Tue, Jul 03, 2012 at 07​:26​:38PM +0200, Leon Timmermans wrote​:

On Tue, Jul 3, 2012 at 7​:15 PM, Jesse Luehrs via RT
<perlbug-followup@​perl.org> wrote​:

Pushed to doy/deprecate_uid_gid_swap. Didn't merge yet because the test
isn't really very accurate, it just checks for any of $&lt;, $&gt;, $(, or $)
being used on both the right and left side of a list assignment, but
would anyone be doing that outside of this context? Detecting an actual
swap would be pretty complicated.

Actually, it's easily and reliably detectable in runtime, pp_aasign
may be a better place to issue the warning, though maybe we'd want to
make sure it doesn't keep giving that warning.

It's not any more detectable at runtime than at compile time - as far as
I can tell, the code in newASSIGNOP that handles the delayed assignment
does so any time any of those variables appear on the lhs of a list
assignment. I could be wrong of course.

-doy