From mjtg@cus.cam.ac.uk

Is is right for Perl to upgrade strings when they're used as rvalues?

  DB<2> $x = "\xff"

  DB<3> Dump $x
SV = PV(0x108238) at 0x1ddfa4
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x209144 "\377"\0 <<<<<<<<< byte encoding
  CUR = 1
  LEN = 2

  DB<4> $y = "\x{100}" . $x

  DB<5> Dump $x
SV = PV(0x108238) at 0x1ddfa4
  REFCNT = 1
  FLAGS = (POK,pPOK,UTF8)
  PV = 0x209144 "\303\277" <<<<<<<< UTF8 encoding
  CUR = 2
  LEN = 4

  DB<6>

I don't see this as explicitly "wrong", but it gives me an uncomfortable
feeling. It certainly complicates life while there are so many other
UTF8 bugs around. And no doubt it provides yet another boobytrap for
5.005 threads.

This is with perl-current as of a few days ago. Note that the -V
output doesn't distinguish it from vanilla 5.6.0. What is the
correct way of identifying / describing these bleading edge versions?

Mike Guy

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration​:
  Platform​:
  osname=solaris, osvers=2.6, archname=sun4-solaris
  uname=''
  config_args='-dOes -f confug.sh'
  hint=previous, useposix=true, d_sigaction=define
  usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
  useperlio=undef d_sfio=undef uselargefiles=define
  use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler​:
  cc='gcc', optimize='-O', gccversion=2.7.2.3
  cppflags='-I/usr/local/include -I/opt/local/include -DREG_INFTY=22786'
  ccflags ='-I/usr/local/include -I/opt/local/include -DREG_INFTY=22786'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags =' -L/usr/local/lib -L/opt/local/lib'
  libpth=/usr/local/lib /opt/local/lib /lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
  libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-fpic', lddlflags='-G -L/usr/local/lib -L/opt/local/lib'

Characteristics of this binary (from libperl)​:
  Compile-time options​: USE_LARGE_FILES
  Built under solaris
  Compiled at May 13 2000 19​:26​:32
  @​INC​:
  /home/mjtg/perl5.6.0x/lib
  /home/mjtg/perl5.6.0x/lib
  /home/mjtg/perl5.6.0x/lib
  /home/mjtg/perl5.6.0x/lib
  .

From @andk

On Tue, 16 May 2000 10​:03​:11 +0100, "M.J.T. Guy" <mjtg@​cus.cam.ac.uk> said​:

This is with perl-current as of a few days ago. Note that the -V
output doesn't distinguish it from vanilla 5.6.0. What is the
correct way of identifying / describing these bleading edge versions?

My impression is there is no good identifier, currently. That's why I
still prefer to rsync the "diffs" directory and run my patchaperlup
hack (which is in my CPAN directory). It's not perfect but at least it
gives you the ability to create fine grained perl versions identified
by complete patches with a number. Given a testcase, it makes it
trivial to find out that patch number (say) 6104 broke or didn't break
this or that.

From @sciurius

andreas.koenig@​anima.de (Andreas J. Koenig) writes​:

On Tue, 16 May 2000 10​:03​:11 +0100, "M.J.T. Guy" <mjtg@​cus.cam.ac.uk> said​:

This is with perl-current as of a few days ago. Note that the -V
output doesn't distinguish it from vanilla 5.6.0. What is the
correct way of identifying / describing these bleading edge versions?

My impression is there is no good identifier, currently. That's why I
still prefer to rsync the "diffs" directory and run my patchaperlup
hack (which is in my CPAN directory). It's not perfect but at least it
gives you the ability to create fine grained perl versions identified
by complete patches with a number.

I guess several of us have something like that.
I, for example, have a script that generates a patch kit out of
Sarathy's nnnn.gz files, and adds an entry to local_patches in
version.h. So at least I know up to which number it was patched.
Being a RedHat Linux user, the script also generates the associated
.spec file which build the .rpm kits.

% rpm -qa | grep perl
bleedperl-6094-1jv

% perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration​:
...
Characteristics of this binary (from libperl)​:
  Compile-time options​: USE_LARGE_FILES
  Locally applied patches​:
  BLEEDPERL - Development patches up to 6094

6094? Wow, need an upgrade...

-- Johan

From The RT System itself

Seems to be okay in the bleadperl. (I'm too tired to think of a test.)