Reversing a default $_ lexicalized in an upper block fails #10426
Comments
From perl@profvince.comCreated by perl@profvince.comWith the latest blead : $ ./perl -Ilib -E '{ my $_ = "foo"; sub z { scalar reverse } } say z' It used to segfault : $ perl5.12.1-64 -M5.010 -E '{ my $_ = "foo"; sub z { scalar reverse } } say z' At that time, the relevant issue was the one addressed in RT #75436. The crash is fixed, but there's still an underlying problem with change 789bd86. For some reason Perl_pad_findlex() (thus find_rundefsv() as well) returns an AV instead of $_ in this case : $ gdb --args ./perl -Ilib -M5.010 -E '{ my $_ = "foo"; sub z { scalar reverse } } say z' Breakpoint 1, Perl_croak (my_perl=0xa08010, Perl Info |
From @cpansproutOn Mon Jun 07 14:35:34 2010, perl@profvince.com wrote:
S_pad_findlex has its own expectations about how its pointer arguments One fix would be to make every sub implicitly close over a lexical $_ I still think we should just deprecate lexical $_. -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @doyOn Thu, Nov 29, 2012 at 05:58:52PM -0800, Father Chrysostomos via RT wrote:
+1, again. -doy |
From @bulk88On Thu Nov 29 17:58:52 2012, sprout wrote:
I like lexical $_. It was added in 5.10. Adding a my is the instinctive -- |
From @ap* bulk88 via RT <perlbug-followup@perl.org> [2012-11-30 08:45]:
But it’s the *only* punctuation variable for which you can do that. You And it is precisely beginners who are ill equipped to understand why … and in the event that they then refuse to use the solution because it So do I. Regards, |
From aaron@priven.comLet's step back a minute. The point of having $_ is to avoid extra typing. The difference between using $_, and a regular variable like $n or $x, is to allow certain operations to proceed without needing to specify a variable at all. So C<for (…)> is the same as C<for $_ (…)>, C<s/x/y/> is the same as C<$_ =~ s/x/y/>, and so forth. And, of course, it also works with a number of core functions, such as alarm (where C<alarm()> is the same as C<alarm($_)>, etc.) It varies, by function. So alarm and chomp, among many others, default to $_, but other functions such as kill, localtime, rand, or sleep do not. User functions with the underscore prototype can do this too (although I think, even with changes in 5.16, it still doesn't really work properly: see http://perlmonks.org/?node_id=958820 ) If you think about it, it is actually extremely weird that a function can, at its own choosing (so to speak), reach up back into the caller's space and take the value of one of the caller's variables. And in some sense, that means that lexical $_ isn't really lexical at all -- at least not in the same sense as lexical $x. "my $x" means that $x is completely hidden from all other scopes unless it is explicitly passed, where "my $_" does not. And this using $_ as the default is the entire purpose of $_ existing in the first place (outside map and grep blocks). So $_ doesn't act like a lexical even if it's declared as one. "my $_" adds a third kind of variable -- global, lexical, and lexical-but-the-calling-function-can-request-its-value. It would be clearer, and more consistent, to have $_ always be global. On Nov 29, 2012, at 11:43 PM, bulk88 via RT <perlbug-followup@perl.org> wrote:
|
From @doyOn Fri, Nov 30, 2012 at 04:25:53PM -0800, Aaron Priven wrote:
Exactly. -doy |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-11-29T20:58:52]
Let's do it. -- |
From @cpansproutOn Sat Dec 01 20:59:32 2012, perl.p5p@rjbs.manxome.org wrote:
Done with commit 90b58ec. -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Sat Dec 01 20:59:32 2012, perl.p5p@rjbs.manxome.org wrote:
Done with commit 90b58ec. -- Father Chrysostomos |
From @cpansproutOn Tue Dec 04 10:54:52 2012, sprout wrote:
BTW, what happened to smartmatch? -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Tue Dec 04 10:54:52 2012, sprout wrote:
BTW, what happened to smartmatch? -- Father Chrysostomos |
From @rjbs* Father Chrysostomos via RT <perlbug-comment@perl.org> [2012-12-04T13:55:10]
Short answer: It seemed to me like interest in creating a version matching the semantics I I think I thought you were not interested in continuing work on that branch, I can review my old mail and try to give a longer answer later. -- |
From @cpansproutOn Tue Dec 04 11:00:21 2012, perl.p5p@rjbs.manxome.org wrote:
In <DFE2CD25-99AA-4FE0-B561-BB8501354BC4@cpan.org> I wrote:
I don’t remember getting a conclusive response from you. Regarding flow control, I have yet to hear a sound proposal that -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Tue Dec 04 11:00:21 2012, perl.p5p@rjbs.manxome.org wrote:
In <DFE2CD25-99AA-4FE0-B561-BB8501354BC4@cpan.org> I wrote:
I don’t remember getting a conclusive response from you. Regarding flow control, I have yet to hear a sound proposal that -- Father Chrysostomos |
From @dcollinsnI'd like to close this ticket, because it was fixed by deprecating and removing lexical $_. (The testcase now reports q{Can't use global $_ in "my"}) However, there's some more recent conversation about "what happened to smartmatch". Since I can't see how this ticket is related to smartmatch, I'm concerned that I'm missing something. Is there still a bug where Perl crashes in this ticket? Any objections to marking this "resolved"? (I'm taking for followup, if you see a problem and intend to fix it, please feel free to assign the ticket to yourself) -- |
From @cpansproutOn Tue Jul 26 12:42:11 2016, dcollinsn@gmail.com wrote:
That was unrelated.
I think you can go ahead and do that. -- Father Chrysostomos |
|
@dcollinsn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#75598 (status was 'resolved')
Searchable as RT75598$
The text was updated successfully, but these errors were encountered: