lexical subs don't seem to honor prototypes

[p5pRT]

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

Searchable as RT116735$

[p5pRT]

From PeterCMartini@GMail.com

Created by petercmartini@gmail.com

lexical subs don't seem to honor prototypes​:

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a 1;'

Get rid of the 'my', and that dies.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.17.9:

Configured by pmartini at Wed Feb  6 02:51:49 EST 2013.

Summary of my perl5 (revision 5 version 17 subversion 9) configuration:
  Derived from: 52a2a812ca95071d6e5d921cf74061d912278729
  Platform:
    osname=linux, osvers=3.2.0-32-generic, archname=i686-linux-thread-multi
    uname='linux pmlinlaptop 3.2.0-32-generic #51-ubuntu smp wed sep
26 21:32:50 utc 2012 i686 i686 i386 gnulinux '
    config_args='-Dusedevel -DDEBUGGING -Dusethreads -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.6.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib
/usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.15'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib
-fstack-protector'

Locally applied patches:



@INC for perl 5.17.9:
    /usr/local/lib/perl5/site_perl/5.17.9/i686-linux-thread-multi
    /usr/local/lib/perl5/site_perl/5.17.9
    /usr/local/lib/perl5/5.17.9/i686-linux-thread-multi
    /usr/local/lib/perl5/5.17.9
    /usr/local/lib/perl5/site_perl
    .


Environment for perl 5.17.9:
    HOME=/home/pmartini
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From PeterCMartini@GMail.com

So, this is because prototype handling operates on an rv pointing to a
cv, and padcv is left out (since there's no rv pointing to it).

Fixing that gets to this little bit of ugliness, as explained in op.c​:

  if (!namegv) { /* expletive! */
  /* XXX The call checker API is public. And it guarantees that
  a GV will be provided with the right name. So we have
  to create a GV. But it is still not correct, as its
  stringification will include the package. What we
  really need is a new call checker API that accepts a
  GV or string (or GV or CV). */

I'm not sure what the best way forward is here.

[p5pRT]

From [Unknown Contact. See original ticket]

So, this is because prototype handling operates on an rv pointing to a
cv, and padcv is left out (since there's no rv pointing to it).

Fixing that gets to this little bit of ugliness, as explained in op.c​:

  if (!namegv) { /* expletive! */
  /* XXX The call checker API is public. And it guarantees that
  a GV will be provided with the right name. So we have
  to create a GV. But it is still not correct, as its
  stringification will include the package. What we
  really need is a new call checker API that accepts a
  GV or string (or GV or CV). */

I'm not sure what the best way forward is here.

[p5pRT]

PeterCMartini@GMail.com - Status changed from 'new' to 'open'

[p5pRT]

From PeterCMartini@GMail.com

The tests for lexical subs (t/cmd/lexsub.t) includes this​:

package main;
{
  sub me ($);
  is prototype eval{\&me}, '$', 'my sub with proto';
  is prototype "me", undef, 'prototype "..." ignores my subs';
}

That last test seems like a bug rather than a feature, and is part of
the reason prototypes don't work with lexical variables - prototypes are
only found if they're looked up via rv2cv, rather than via the new padcv
op.

If we can agree that that test should also return '$', then I can submit
a patch (for review) that gets prototypes working for lexical subs.

It's a rather involved patch...

[p5pRT]

From [Unknown Contact. See original ticket]

The tests for lexical subs (t/cmd/lexsub.t) includes this​:

package main;
{
  sub me ($);
  is prototype eval{\&me}, '$', 'my sub with proto';
  is prototype "me", undef, 'prototype "..." ignores my subs';
}

That last test seems like a bug rather than a feature, and is part of
the reason prototypes don't work with lexical variables - prototypes are
only found if they're looked up via rv2cv, rather than via the new padcv
op.

If we can agree that that test should also return '$', then I can submit
a patch (for review) that gets prototypes working for lexical subs.

It's a rather involved patch...

[p5pRT]

From @rgarcia

On 17 February 2013 06​:36, Peter Martini via RT
<perlbug-comment@​perl.org> wrote​:

The tests for lexical subs (t/cmd/lexsub.t) includes this​:

package main;
{
sub me ($);
is prototype eval{\&me}, '$', 'my sub with proto';
is prototype "me", undef, 'prototype "..." ignores my subs';
}

That last test seems like a bug rather than a feature, and is part of
the reason prototypes don't work with lexical variables - prototypes are
only found if they're looked up via rv2cv, rather than via the new padcv
op.

If we can agree that that test should also return '$', then I can submit
a patch (for review) that gets prototypes working for lexical subs.

It's a rather involved patch...

In any event, I think that either 5.18 should have lexical-sub
prototypes working, or warning (or dying?) just to make sure no-one
starts writing code that assumes the current behaviour is correct...

[p5pRT]

From PeterCMartini@GMail.com

On Mon, Feb 18, 2013 at 3​:47 AM, Rafael Garcia-Suarez <rgs@​consttype.org> wrote​:

On 17 February 2013 06​:36, Peter Martini via RT
<perlbug-comment@​perl.org> wrote​:

The tests for lexical subs (t/cmd/lexsub.t) includes this​:

package main;
{
sub me ($);
is prototype eval{\&me}, '$', 'my sub with proto';
is prototype "me", undef, 'prototype "..." ignores my subs';
}

That last test seems like a bug rather than a feature, and is part of
the reason prototypes don't work with lexical variables - prototypes are
only found if they're looked up via rv2cv, rather than via the new padcv
op.

If we can agree that that test should also return '$', then I can submit
a patch (for review) that gets prototypes working for lexical subs.

It's a rather involved patch...

In any event, I think that either 5.18 should have lexical-sub
prototypes working, or warning (or dying?) just to make sure no-one
starts writing code that assumes the current behaviour is correct...

We're in good shape on that point​:

perl5.17.9 -E 'my sub foo {say @​_} foo 1;'
Experimental "my" subs not enabled at -e line 1.

perl5.17.9 -Mfeature=lexical_subs -E 'my sub foo {say @​_} foo 1;'
The lexical_subs feature is experimental at -e line 1.
1

It warns no matter what, but doesn't even execute unless you
specifically enable it.

[p5pRT]

From PeterCMartini@GMail.com

On Tue Feb 12 20​:53​:03 2013, pcm wrote​:

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

-----------------------------------------------------------------
[Please describe your issue here]

lexical subs don't seem to honor prototypes​:

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a 1;'

Get rid of the 'my', and that dies.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags​:
category=core
severity=low
---
Site configuration information for perl 5.17.9​:

Configured by pmartini at Wed Feb 6 02​:51​:49 EST 2013.

Summary of my perl5 (revision 5 version 17 subversion 9)
configuration​:
Derived from​: 52a2a81
Platform​:
osname=linux, osvers=3.2.0-32-generic, archname=i686-linux-thread-
multi
uname='linux pmlinlaptop 3.2.0-32-generic #51-ubuntu smp wed sep
26 21​:32​:50 utc 2012 i686 i686 i386 gnulinux '
config_args='-Dusedevel -DDEBUGGING -Dusethreads -des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define,
usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler​:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.6.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries​:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib
/usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.15'
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib
-fstack-protector'

Locally applied patches​:

---
@​INC for perl 5.17.9​:
/usr/local/lib/perl5/site_perl/5.17.9/i686-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.17.9
/usr/local/lib/perl5/5.17.9/i686-linux-thread-multi
/usr/local/lib/perl5/5.17.9
/usr/local/lib/perl5/site_perl
.

---
Environment for perl 5.17.9​:
HOME=/home/pmartini
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/usr/lib/lightdm/lightdm​:/usr/local/sbin​:/usr/local/bin​:/usr/sbin​:/
usr/bin​:/sbin​:/bin​:/usr/games

PERL\_BADLANG \(unset\)
SHELL=/bin/bash

Further testing​:

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a 1;'

Does not check prototypes.

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a(1);'

*Does* check prototypes.

The difference is the second one generates an rv2cv pointing to the
padcv, while the first one uses the padcv directly.

I'd been playing with ways to fix this, and checked in my work-in-
progress (as a single large-ish commit) this morning​:
PeterMartini@lexical-proto

There are two components, which are separable​:

1. Change ck_subr to grab the CV directly from padcv if that's the last
op, which is the simple fix, and I'll defer to anyone more knowledgeable
on whether it's the correct fix.

2. Father C had noted that the Perl_call_checker API passes a GV*, which
no longer works, since a lexical sub won't have a GV. The solution as
of right now is a faked up GV, which as noted is not ideal, as it
includes the current package.

I added an alternate API, Perl_call_checker_sv and appropriate get/set
functions, so that the name could be passed be specified as an SV*. For
backwards compatibility reasons, if a custom Perl_call_checker was set,
it will use that; if a custom Perl_call_checker_sv was set, it will use
that; otherwise, it will use the default Perl_call_checker_sv.

These both get stored in checkcall magic, so only one can be active at a
time. If the current, GV form, is used in a set, and the SV form is
used in a get, the get returns a NULL pointer. In the reverse case,
where the new API is used to set an override, and the old API is used to
get it back, the code will croak. The reason for the difference is the
old API implies the call will always succeed, so returning a NULL would
be a bad idea, while the new version is documented to return NULL to
indicate that the alternate API should be used.

************

Now that I see that prototypes are actually partially honored, applying
just the first part would get us to consistency with minimal risk of
side effects, and the second part can be polished up as a nice to have.

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue Feb 12 20​:53​:03 2013, pcm wrote​:

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

-----------------------------------------------------------------
[Please describe your issue here]

lexical subs don't seem to honor prototypes​:

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a 1;'

Get rid of the 'my', and that dies.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags​:
category=core
severity=low
---
Site configuration information for perl 5.17.9​:

Configured by pmartini at Wed Feb 6 02​:51​:49 EST 2013.

Summary of my perl5 (revision 5 version 17 subversion 9)
configuration​:
Derived from​: 52a2a81
Platform​:
osname=linux, osvers=3.2.0-32-generic, archname=i686-linux-thread-
multi
uname='linux pmlinlaptop 3.2.0-32-generic #51-ubuntu smp wed sep
26 21​:32​:50 utc 2012 i686 i686 i386 gnulinux '
config_args='-Dusedevel -DDEBUGGING -Dusethreads -des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define,
usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler​:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.6.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries​:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib
/usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.15'
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib
-fstack-protector'

Locally applied patches​:

---
@​INC for perl 5.17.9​:
/usr/local/lib/perl5/site_perl/5.17.9/i686-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.17.9
/usr/local/lib/perl5/5.17.9/i686-linux-thread-multi
/usr/local/lib/perl5/5.17.9
/usr/local/lib/perl5/site_perl
.

---
Environment for perl 5.17.9​:
HOME=/home/pmartini
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/usr/lib/lightdm/lightdm​:/usr/local/sbin​:/usr/local/bin​:/usr/sbin​:/
usr/bin​:/sbin​:/bin​:/usr/games

PERL\_BADLANG \(unset\)
SHELL=/bin/bash

Further testing​:

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a 1;'

Does not check prototypes.

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a(1);'

*Does* check prototypes.

The difference is the second one generates an rv2cv pointing to the
padcv, while the first one uses the padcv directly.

I'd been playing with ways to fix this, and checked in my work-in-
progress (as a single large-ish commit) this morning​:
PeterMartini@lexical-proto

There are two components, which are separable​:

1. Change ck_subr to grab the CV directly from padcv if that's the last
op, which is the simple fix, and I'll defer to anyone more knowledgeable
on whether it's the correct fix.

2. Father C had noted that the Perl_call_checker API passes a GV*, which
no longer works, since a lexical sub won't have a GV. The solution as
of right now is a faked up GV, which as noted is not ideal, as it
includes the current package.

I added an alternate API, Perl_call_checker_sv and appropriate get/set
functions, so that the name could be passed be specified as an SV*. For
backwards compatibility reasons, if a custom Perl_call_checker was set,
it will use that; if a custom Perl_call_checker_sv was set, it will use
that; otherwise, it will use the default Perl_call_checker_sv.

These both get stored in checkcall magic, so only one can be active at a
time. If the current, GV form, is used in a set, and the SV form is
used in a get, the get returns a NULL pointer. In the reverse case,
where the new API is used to set an override, and the old API is used to
get it back, the code will croak. The reason for the difference is the
old API implies the call will always succeed, so returning a NULL would
be a bad idea, while the new version is documented to return NULL to
indicate that the alternate API should be used.

************

Now that I see that prototypes are actually partially honored, applying
just the first part would get us to consistency with minimal risk of
side effects, and the second part can be polished up as a nice to have.

[p5pRT]

From PeterCMartini@GMail.com

Father C -

This change​:

Inline Patch

diff --git a/op.c b/op.c
index c9a1b53..9c2d06a 100644
--- a/op.c
+++ b/op.c
@@ -8135,7 +8135,6 @@ Perl_newCVREF(pTHX_ I32 flags, OP *o)
        dVAR;
        o->op_type = OP_PADCV;
        o->op_ppaddr = PL_ppaddr[OP_PADCV];
-       return o;
     }
     return newUNOP(OP_RV2CV, flags, scalar(o));
 }

Seems like it should be sufficient for the fix, but it's causing assertion failures on assert\(hek\) in the case of a const sub​:

'my sub if(){44} if;' # boom!

I haven't been able to chase down a fix for that part yet, though.

[p5pRT]

From [Unknown Contact. See original ticket]

Father C -

This change​:

Inline Patch

diff --git a/op.c b/op.c
index c9a1b53..9c2d06a 100644
--- a/op.c
+++ b/op.c
@@ -8135,7 +8135,6 @@ Perl_newCVREF(pTHX_ I32 flags, OP *o)
        dVAR;
        o->op_type = OP_PADCV;
        o->op_ppaddr = PL_ppaddr[OP_PADCV];
-       return o;
     }
     return newUNOP(OP_RV2CV, flags, scalar(o));
 }

Seems like it should be sufficient for the fix, but it's causing assertion failures on assert\(hek\) in the case of a const sub​:

'my sub if(){44} if;' # boom!

I haven't been able to chase down a fix for that part yet, though.

[p5pRT]

From @chipdude

On 2/16/2013 9​:36 PM, Peter Martini via RT wrote​:

package main;
{
sub me ($);
is prototype eval{\&me}, '$', 'my sub with proto';
is prototype "me", undef, 'prototype "..." ignores my subs';
}

That last test seems like a bug rather than a feature, and is part of
the reason prototypes don't work with lexical variables - prototypes are
only found if they're looked up via rv2cv, rather than via the new padcv
op.

This test seems fine. After all, compare with scalars. While $me
might be a lexical, ${"me"} never is. Why should & break this pattern?

Which isn't to say that lexical subs should ignore prototypes.

[p5pRT]

From PeterCMartini@GMail.com

On Tue, Feb 19, 2013 at 9​:38 PM, Reverend Chip <rev.chip@​gmail.com> wrote​:

On 2/16/2013 9​:36 PM, Peter Martini via RT wrote​:

package main;
{
sub me ($);
is prototype eval{\&me}, '$', 'my sub with proto';
is prototype "me", undef, 'prototype "..." ignores my subs';
}

That last test seems like a bug rather than a feature, and is part of
the reason prototypes don't work with lexical variables - prototypes are
only found if they're looked up via rv2cv, rather than via the new padcv
op.

This test seems fine. After all, compare with scalars. While $me
might be a lexical, ${"me"} never is. Why should & break this pattern?

Ah, that makes sense, and proves the point that my original approach
was too hackish for its own good.

Removing the early return in newCVREF certainly looks like a much
saner (and smaller) fix, but I haven't had a chance to look into why
the conversion to a const sub causes so much trouble.

Which isn't to say that lexical subs should ignore prototypes.

[p5pRT]

From @cpansprout

On Mon Feb 18 10​:55​:41 2013, pcm wrote​:

On Tue Feb 12 20​:53​:03 2013, pcm wrote​:
Further testing​:

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a 1;'

Does not check prototypes.

perl5.17.9 -Mfeature=lexical_subs -e 'my sub a($$){} a(1);'

*Does* check prototypes.

The difference is the second one generates an rv2cv pointing to the
padcv, while the first one uses the padcv directly.

I'd been playing with ways to fix this, and checked in my work-in-
progress (as a single large-ish commit) this morning​:
PeterMartini@lexical-proto

There are two components, which are separable​:

1. Change ck_subr to grab the CV directly from padcv if that's the last
op, which is the simple fix, and I'll defer to anyone more knowledgeable
on whether it's the correct fix.

I’ve done what I think is the more correct fix, which is to avoid
generating two disparate op trees to begin with, in commit 9a5e6f3.

2. Father C had noted that the Perl_call_checker API passes a GV*, which
no longer works, since a lexical sub won't have a GV. The solution as
of right now is a faked up GV, which as noted is not ideal, as it
includes the current package.

I added an alternate API, Perl_call_checker_sv and appropriate get/set
functions, so that the name could be passed be specified as an SV*. For
backwards compatibility reasons, if a custom Perl_call_checker was set,
it will use that; if a custom Perl_call_checker_sv was set, it will use
that; otherwise, it will use the default Perl_call_checker_sv.

These both get stored in checkcall magic, so only one can be active at a
time. If the current, GV form, is used in a set, and the SV form is
used in a get, the get returns a NULL pointer. In the reverse case,
where the new API is used to set an override, and the old API is used to
get it back, the code will croak. The reason for the difference is the
old API implies the call will always succeed, so returning a NULL would
be a bad idea, while the new version is documented to return NULL to
indicate that the alternate API should be used.

************

Now that I see that prototypes are actually partially honored, applying
just the first part would get us to consistency with minimal risk of
side effects, and the second part can be polished up as a nice to have.

Would you be willing to do that? :-)

One thing I thought about was to create a new API function, maybe called
cv_name, which can be passed, a CV, a GV, or any stringifiable SV. It
would return an SV containing the name of the sub (a new mortal for a CV
or GV; the SV itself otherwise).

Whatever value is passed through the new call checker API could be
passed through to cv_name when an error is reported.

--

Father Chrysostomos