BBC: Blead Breaks overload::substr

[cjg-cguevara]

This is a bug report for perl from "Carlos Guevara" [email protected],
generated with the help of perlbug 1.43 running under perl 5.41.8.

---

BBC: Blead Breaks overload::substr

Please see http://fast-matrix.cpantesters.org/?dist=overload::substr

---

Flags

• category=core
• severity=low

---

Perl configuration

Site configuration information for perl 5.41.8:

Configured by cpan at Sat Jan 18 12:32:48 EST 2025.

Summary of my perl5 (revision 5 version 41 subversion 8) configuration:
  Commit id: ce43abaca21b9ad4a5c671736ae906f514169919
  Platform:
    osname=linux
    osvers=5.14.0-503.21.1.el9_5.x86_64
    archname=x86_64-linux
    uname='linux cjg-rhel9 5.14.0-503.21.1.el9_5.x86_64 #1 smp preempt_dynamic thu dec 19 09:37:00 est 2024 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Dprefix=/home/cpan/bin/perl -Dscriptdir=/home/cpan/bin/perl/bin -Dusedevel -Duse64bitall'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='cc'
    ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-O2'
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='11.5.0 20240719 (Red Hat 11.5.0-2)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    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-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /usr/lib64 /usr/local/lib64
    libs=-lpthread -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=/lib/../lib64/libc.so.6
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.34'
  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-strong'


---
@INC for perl 5.41.8:
    /home/cpan/bin/perl/lib/site_perl/5.41.8/x86_64-linux
    /home/cpan/bin/perl/lib/site_perl/5.41.8
    /home/cpan/bin/perl/lib/5.41.8/x86_64-linux
    /home/cpan/bin/perl/lib/5.41.8

---
Environment for perl 5.41.8:
    HOME=/home/cpan
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/cpan/bin/perl/bin:/home/cpan/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[richardleach]

This module overloads substr. Likely it needs a patch so it can handle the new OP_SUBSTR_LEFT op. I'll take a look·

[jkeenan]

Bisection (conducted manually) indicates that commit cdbed2a is the first bad commit.

cdbed2a40eb1292d5be2fd59c091cf78f6a4be69
Author:     Richard Leach <[email protected]>
AuthorDate: Tue Nov 19 23:02:37 2024 +0000
Commit:     Richard Leach <[email protected]>
CommitDate: Mon Jan 13 22:11:16 2025 +0000

    OP_SUBSTR_LEFT - a specialised OP_SUBSTR variant

@richardleach ^^

[richardleach]

Modifying substr.xs, I've got as far as:

1. Adding OP *(*real_pp_substr_left)(pTHX);
2. Changing the BOOT section to:

BOOT:
if(!init_done++) {
  real_pp_substr = PL_ppaddr[OP_SUBSTR];
  PL_ppaddr[OP_SUBSTR] = &Perl_pp_overload_substr;

  /* TODO GUARD THIS SOMEHOW? */
  real_pp_substr_left = PL_ppaddr[OP_SUBSTR_LEFT];
  PL_ppaddr[OP_SUBSTR_LEFT] = &Perl_pp_overload_substr_left;
}

3. Adding a new PP wrapper:

PP(pp_overload_substr_left) {
  dSP; dTARG;
  const int num_args = PL_op->op_private & 7; /* Horrible; stolen from pp.c:pp_subst */

  /* Self and a length SV should be the only args on the stack for this OP.*/
  SV *length = *SP;
  SV *self   = *(SP - 1);
  GV *substr_method;
  SV *result;

  if(!sv_isobject(self))
    return (*real_pp_substr_left)(aTHX);

  substr_method = gv_fetchmeth(SvSTASH(SvRV(self)), "(substr", 7, 0);

  if(!substr_method)
    return (*real_pp_substr)(aTHX);

  ENTER;
  SAVETMPS;

  /* Stack fixups required. Better make sure the stack is big enough. */
  EXTEND(SP, 2);

  /* Create a zero IV for the offset and insert it. */
  *SP = sv_2mortal(newSViv(0));
  *++SP = length;

  /* If an empty replacement string is needed, create and insert it. */
  if (num_args == 4) {
    SV *repl = NULL;
    repl = newSVpvn_flags("", 0, SVs_TEMP);
    *++SP = repl;
  }

  /* We can proceed now as per pp_overload_substr */

  /* This piece of evil trickery "pushes" all the args we already have on the
   * stack, by simply claiming the MARK to be at the bottom of this op's args
   */
  PUSHMARK(SP-(num_args+1));

  PUTBACK;

  call_sv((SV*)GvCV(substr_method), G_SCALAR);

  SPAGAIN;
  result = POPs;

  SvREFCNT_inc(result);

  FREETMPS;
  LEAVE;

  XPUSHs(result);

  RETURN;
}

But even when XPUSHs(result) pushes a SV that does indeed contain the correct value, something seems to be going amiss on the stack. For example, from t/02object.t:

$s = substr( $str, 0, 5 );
is( $s, "Hello", 'substr extraction' );

The XPUSHs(result) does push the Hello SV onto the stack, but the test fails with:

not ok 1 - substr extraction
#   Failed test 'substr extraction'
#   at t/02object.t line 40.
#          got: undef
#     expected: 'Hello'

[richardleach]

But even when XPUSHs(result) pushes a SV that does indeed contain the correct value, something seems to be going amiss on the stack.

Possibly something to do with overload_substr_ctx? I don't understand yet what that's for/doing.

[jkeenan]

Let's loop in the upstream author: @leonerd, can you take a look?

[jkeenan]

Let's loop in the upstream author: @leonerd, can you take a look?

@leonerd can you please take a look at this BBC ticket? Thanks.

[eserte]

An RT issue already exists: https://rt.cpan.org/Ticket/Display.html?id=160458

[haarg]

The module has been fixed.