*foo{SCALAR} autovivifies #10241
Comments
From zefram@fysh.orgCreated by zefram@fysh.org$ perl -lwe 'sub foo; print *foo{SCALAR}' $ *foo{SCALAR} is autovivifying the scalar slot of the GV, whereas It looks like this is historical crud from a time when the SV slot was Perl Info |
From @raflThis patch does the suggested change and adjusts the tests for the |
From @rafl0001-Stop-foo-SCALAR-from-autovivifying-the-SV-slot.patchFrom 53432edbd743f02af3d1b2b8ad7ad144b0cb1530 Mon Sep 17 00:00:00 2001
From: Florian Ragwitz <rafl@debian.org>
Date: Mon, 15 Nov 2010 05:10:17 +0100
Subject: [PATCH] Stop *foo{SCALAR} from autovivifying the SV slot
This gets things into sync with *foo{ARRAY} et.al.
---
pp.c | 2 +-
t/op/gv.t | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/pp.c b/pp.c
index 9e762d5..af18a41 100644
--- a/pp.c
+++ b/pp.c
@@ -675,7 +675,7 @@ PP(pp_gelem)
break;
case 'S':
if (strEQ(second_letter, "CALAR"))
- tmpRef = GvSVn(gv);
+ tmpRef = GvSV(gv);
break;
}
}
diff --git a/t/op/gv.t b/t/op/gv.t
index f04bda0..2150c3b 100644
--- a/t/op/gv.t
+++ b/t/op/gv.t
@@ -524,8 +524,8 @@ foreach my $value ([1,2,3], {1=>2}, *STDOUT{IO}, \&ok, *STDOUT{FORMAT}) {
$g = \*vowm;
$r = eval {use strict; ${*{$g}{SCALAR}}};
- is ($@, '',
- "PERL_DONT_CREATE_GVSV shouldn't affect thingy syntax under strict");
+ like ($@, qr/^Can't use an undefined value as a SCALAR reference/,
+ "PERL_DONT_CREATE_GVSV should affect thingy syntax under strict");
}
{
--
1.7.2.3
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Sun Nov 14 20:13:28 2010, rafl wrote:
Yes, please! |
From zefram@fysh.orgFlorian Ragwitz via RT wrote:
I already posted a patch with slightly more extensive tests. -zefram |
From @raflZefram <zefram@fysh.org> writes:
I wasn't aware of that. You're patch is obviously better. I'd love for |
From zefram@fysh.orgFlorian Ragwitz wrote:
When I posted mine some months ago, no one objected, though there was some -zefram |
From @nwc10On Mon, Nov 15, 2010 at 09:40:28AM +0000, Zefram wrote:
Very odd, but very old.
I'm not *comfortable* with the change. When I changed the internals, to not I was part-way through trying to work out what on CPAN references # PASS: Acme-Pr0n/lib/Acme/Pr0n.pm Moose Which I count as 16 (/will break/i + /BREAKS/i) Nicholas Clark |
From @demerphqOn 15 November 2010 11:00, Nicholas Clark <nick@ccl4.org> wrote:
Indeed. See the comment from Sarathy in Data::Dumper. next if Im not against this change, but i do think it has thepotential to break a lot. Yves -- |
From @ap* Nicholas Clark <nick@ccl4.org> [2010-11-15 11:05]:
How about a deprecation cycle then? I know I have personally written code that relied on this I also know that all of the code I wrote was to work around, And I remember that this behaviour *prevented* me from doing I can’t really imagine any way in which this behaviour makes I would gladly have this old code of mine broken and I’ll bet If this can be achieved, even if it takes some work to get there, I’m thinking of a deprecation warning when *foo{SCALAR} used as Regards, |
From @doyWhat needs to happen to move forward here? Could this perhaps get a full -doy |
From @rjbs* Jesse Luehrs via RT <perlbug-followup@perl.org> [2012-07-04T18:32:54]
Want to give a go at using Steffen's machinery for that? I bet it could use a -- |
From @cpansproutOn Mon Nov 15 02:00:48 2010, nicholas wrote:
If we allow *foo{SCALAR} *assignment*, and deferred element magic too, (I would like to make glob elements assignable for other reasons, too. -- Father Chrysostomos |
Migrated from rt.perl.org#73666 (status was 'open')
Searchable as RT73666$
The text was updated successfully, but these errors were encountered: