[perl #116735] lexical subs don't seem to honor prototypes

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: 
> https://github.com/PeterMartini/perl/commit/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 9a5e6f3cd84.

> 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


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=116735

• [perl #116735] lexical subs don't seem to honor prototypes by Father Chrysostomos via RT
• [perl #116735] lexical subs don't seem to honor prototypes by Father Chrysostomos via RT
• [perl #116735] lexical subs don't seem to honor prototypes by Father Chrysostomos via RT
• Re: [perl #116735] lexical subs don't seem to honor prototypes by Ricardo Signes
• Re: [perl #116735] lexical subs don't seem to honor prototypes by Peter Martini
• [perl #116735] lexical subs don't seem to honor prototypes by Father Chrysostomos via RT
• [perl #116735] lexical subs don't seem to honor prototypes by Father Chrysostomos via RT