New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prototypes defined too late - warning for recursive subroutines #1511
Comments
From ht.000@foa.dkCreated by ht000@foa.dkWhen running with -w flag you get a warning if a function with a Eg: fail (1); Perl5.005_03 does not exhibit this behaviour (possibly because the The warning can be avoided by prototyping the subroutine just before fail (1); A more intuitive behaviour would be that the prototype is known at the At the least a warning/note should be added in perlfunc.pod --- Perl Info
|
From mrcoraza@an.intel.comWe're trying out the new 5.6 release. This version has introduced eval 'exec perl -w -S Note that I am using the -w option. I get the following. main::fact() called too early to check prototype at rec line 12. I can work around the problem easily by explicitly pre-declaring the Thanks. - Miguel P.S. I think this has always been sort of a problem since I've noticed P.P.S. FYI we're also noting some seg faults in certain apps using Tk. Perl Info
|
From ht.000@foa.dkCreated by ht000@foa.dkWhen running with -w flag you get a warning if a function with a Eg: fail (1); Perl5.005_03 does not exhibit this behaviour (possibly because the The warning can be avoided by prototyping the subroutine just before fail (1); A more intuitive behaviour would be that the prototype is known at the At the least a warning/note should be added in perlfunc.pod --- Perl Info
|
From @ysthIn article <Pine.OSF.3.95.1000410145750.22120C-100000@sula1.foa.dk>,
That could cause some serious backward compatibility problems. Given Booboo.pm: package Booboo; Try: perl -MBooboo -e 'Booboo(1,2,3)' Then try it again with the declaration uncommented.
Perhaps perlsub? |
From [Unknown Contact. See original ticket]patchit |
From ziggy@panix.comExecutive summary: prototypes exist but cannot be checked inside a recursive function. |
@smpeters - Status changed from 'resolved' to 'open' |
1 similar comment
@smpeters - Status changed from 'resolved' to 'open' |
From @wolfsageOn Mon Apr 10 08:31:35 2000, RT_System wrote:
Hmm, isn't that wrong and broken? Shouldn't sub Booboo(@); sub Booboo(@) { ... } behave the same as the Having it behave differently when it's predeclared seems very surprising. The above can be fixed by: sub Booboo(@) { Booboo::->new(@_) } Is back-compat preventing this from being fixed? If so, how do we go |
From @cpansproutOn Sun Nov 25 05:08:34 2012, alh wrote:
Well, the current behaviour *is* consistent with how my-scoping works. Also, what happens when the subroutine contains a syntax error and there -- Father Chrysostomos |
From PeterCMartini@GMail.comOn Sun, Nov 25, 2012 at 10:12 AM, Father Chrysostomos via RT <
The natural change would be from: sub foo($$); -- sets to sub foo($$); -- sets So, 'sub foo( On the other hand, 'sub foo; sub foo($$){ SYNTAX ERROR }' would change the Do you have a use case in mind where that would matter? And does anyone know if there is any documentation to suggest that the
|
From @cpansproutOn Sun Nov 25 10:05:06 2012, pcm wrote:
No. But I want to point out that this would break compatibility in four • Barewords
I think the general consensus in the past has been that this is not a -- Father Chrysostomos |
From PeterCMartini@GMail.comOn Sun, Nov 25, 2012 at 3:46 PM, Father Chrysostomos via RT <
Ah, barewords make a strong argument: sub STDOUT { That's persuasive enough for me to drop the argument, much as I wish it
|
From @cpansproutOn Sun Nov 25 13:06:36 2012, pcm wrote:
I think this is the appropriate place to bring up the joke about the -- Father Chrysostomos |
From @nwc10On Sun, Nov 25, 2012 at 01:33:33PM -0800, Father Chrysostomos via RT wrote:
Yes. :-( Given that where we are right now is that bareword parsing behaves as above, I'm not sure where such tests should go. Nicholas Clark |
From PeterCMartini@GMail.comOn Mon Dec 03 05:02:36 2012, nicholas wrote:
For the sake of argument, and to clean up an old RT that's ultimately I'm more than happy to see an alternate patch with better wording, or in |
From PeterCMartini@GMail.com0001-perl-2726-Prototype-is-not-applied-until-BLOCK-is-de.patchFrom 48597a2adb2b6a01e9bfdb94d1598ea3c6d91bbf Mon Sep 17 00:00:00 2001
From: Peter Martini <PeterCMartini@GMail.com>
Date: Tue, 6 Aug 2013 03:16:35 -0400
Subject: [PATCH] [perl #2726] Prototype is not applied until BLOCK is defined
In the case of a sub definition with a prototype, the prototype
is not attached to the sub until after the body is completely
defined. This means that any sub which calls itself will
not honor its prototype unless the prototype was declared prior to
the sub's definition. Whether or not this behavior is desirable is
debatable, but its far too late to do anything about it other than
document it and test to make sure it doesn't change.
---
pod/perlsub.pod | 10 ++++++++++
t/comp/proto.t | 9 ++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/pod/perlsub.pod b/pod/perlsub.pod
index ff5feb5..455fa23 100644
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -1338,6 +1338,16 @@ C<func()> now gets passed in a C<1>; that is, the number of elements
in C<@foo>. And the C<split> gets called in scalar context so it
starts scribbling on your C<@_> parameter list. Ouch!
+If a sub has both a PROTO and a BLOCK, the prototype is not applied
+until after the BLOCK is completely defined. This means that a recursive
+function with a prototype has to be predeclared for the prototype to take
+effect, like so:
+
+ sub foo($$);
+ sub foo($$) {
+ foo 1, 2;
+ }
+
This is all very powerful, of course, and should be used only in moderation
to make the world a better place.
diff --git a/t/comp/proto.t b/t/comp/proto.t
index 947a232..47ebf74 100644
--- a/t/comp/proto.t
+++ b/t/comp/proto.t
@@ -18,7 +18,7 @@ BEGIN {
# strict
use strict;
-print "1..199\n";
+print "1..201\n";
my $i = 1;
@@ -559,6 +559,13 @@ print "ok ", $i++, " star3 STDERR\n";
print "not " unless eval 'star4 STDERR; 1';
print "ok ", $i++, " star4 STDERR\n";
+# [perl #2726]
+# Test that prototype binding is late
+print "not " unless eval 'sub l564($){ l564(); } 1';
+print "ok ", $i++, " prototype checking not done within initial definition\n";
+print "not " if eval 'sub l566($); sub l566($){ l566(); } 1';
+print "ok ", $i++, " prototype checking done if sub pre-declared\n";
+
# test scalarref prototype
sub sreftest (\$$) {
print "not " unless ref $_[0];
--
1.7.9.5
|
From @cpansproutOn Tue Aug 06 00:36:02 2013, pcm wrote:
Thank you. Applied as 1cd19e1. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#2726 (status was 'resolved')
Searchable as RT2726$
The text was updated successfully, but these errors were encountered: