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
CLONE_SKIP doesn't result in undef copies #9093
Comments
From olly@survex.comCreated by olly@survex.com"perldoc perlmod" says: Like "CLONE", "CLONE_SKIP" is called once per package; however, it is But in my tests, the copies are unblessed, but aren't undef. Here's a ## Class.pm: package Class; use strict; sub CLONE_SKIP { 1 } sub new { bless {} } 1; ## cloneskip.pl: #!/usr/bin/perl -W my $obj = Class->new(); sub check_obj { check_obj("main"); Output from "perl clone_skip.pl": main: ref($obj) = Class thread: ref($obj) = SCALAR main: ref($obj) = Class The documentation leads me to expect the third and fourth non-blank lines thread: ref($obj) = as that is what I get if I change cloneskip.pl to do this: my $thread1 = threads->create(sub { $obj = undef; check_obj("thread"); 1; } ); The documented behaviour seems sensible, so I think the bug here is in the Cheers, Perl Info
|
From @iabynOn Tue, Oct 30, 2007 at 07:40:27PM -0700, Olly Betts wrote:
The documentation is ambiguous, but the current behaviour of perl is as use threads; gives: $VAR1 = bless( {}, 'main' ); However, looking at the code I noticed that there *is* a bug, in that the Change 32213 by davem@davem-pigeon on 2007/11/02 23:59:27 [perl #47045] CLONE_SKIP doesn't result in undef copies Affected files ... ... //depot/perl/pod/perlmod.pod#42 edit Differences ... ==== //depot/perl/pod/perlmod.pod#42 (text) ==== @@ -581,6 +581,9 @@ ==== //depot/perl/sv.c#1438 (text) ==== @@ -10048,8 +10048,7 @@ /* don't clone objects whose class has asked us not to */ -- |
The RT System itself - Status changed from 'new' to 'open' |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#47045 (status was 'resolved')
Searchable as RT47045$
The text was updated successfully, but these errors were encountered: