Re: LVALUE refs

I haven't checked the sources, but empirical evidence made it clear to me there is only one LVALUE object per lexical occurrance of 'substr'.

This means for example that while this works:

$x = \substr("blah", 1, 2);
$y = \substr("florp", 1, 3);
print "$$x $$y\n";
[download]

this will not:

sub substrref { \substr($_[0], $_[1], $_[2]) }
$x = substrref("blah", 1, 2);
$y = substrref("florp", 1, 3);
print "$$x $$y\n";
[download]

The work-around is to create a new lexical occurrance each time, by using eval STRING:

sub substrref { eval '\substr($_[0], $_[1], $_[2])' }
$x = substrref("blah", 1, 2);
$y = substrref("florp", 1, 3);
print "$$x $$y\n";
[download]

I hope this helps :-)

(The obvious real solution is that substr() should check the refcount of the PVLV-object and create a fresh one if someone is still holding a reference to the previous one)

Comment on Re: LVALUE refs Select or Download Code

Replies are listed 'Best First'.
Re: Re: LVALUE refs by Elian (Parson) on Feb 16, 2003 at 16:03 UTC
I haven't checked the sources, but empirical evidence made it clear... This is one of the single most dangerous statements you can make. Perl is a programming language, not an archaeological dig or a physics experiment. Use the docs and, when they prove inadequate, read the source and check with p5p to see if what you found happens on purpose or accidentally. Assuming "found" behaviour will persist in future versions of perl is just asking for bizarre bugs and major breakage later on--if it's not documented to work a particular way, you shouldn't assume that it will. (And yes, I know perl's docs are insufficiently rigorous to really make this statement about any of its behaviours, but the point still holds--if you had to experiment to find behaviours, and can't find reference to them in the docs, you shouldn't count on the behaviours)	[reply]
Re: Re: Re: LVALUE refs by xmath (Hermit) on Feb 16, 2003 at 19:49 UTC
I didn't mean to imply this was The Way, For Now And Ever. I simply observed perl's current behavior, and a work-around for this current behavior. (I don't think any docs talk about this issue)	[reply]
Re: Re: Re: Re: LVALUE refs by Elian (Parson) on Feb 20, 2003 at 16:32 UTC
Sorry, didn't mean to get cranky at you specifically. Perl's a huge language, with docs that are less than specific in spots, so lots of folks have an "experiment and find out" mentality that ultimately results in code that breaks. Just as a for example, if the hashing algorithm made it so that keys came out sorted by the third character, for some bizarre reason, someone would figure that out and use it in production code, which'd break if the hash function changes at some point in the future. (Perl's hashing function has already changed at least once, and it has broken some people's code) As one of the folks who actually implements perl, and sometimes changes the implementation, what I really hate is the potential that a change to undocumented behaviour can break user code. It's not something we like doing, and we try not to, but there's always that potential, and you're more likely to find bizarre undocumented edge cases just poking around. Hence the grumbly warning--while you may find interesting behaviour while exploring, unless it's backed by documentation you should assume that it may change in a future (or past) release.	[reply]
Re: Re: LVALUE refs by BrowserUk (Patriarch) on Feb 16, 2003 at 19:31 UTC
Thanks for reporting your findings, I too am a great believer in empirical evidence, even if only as a prelude to verification via other routes. Deriving this understanding from the Perl sources would require considerably more familiarity than I currently have, or am likely to expend the time to aquire. Whilst I love Perl as a language, I absolutely hate having to delve into the source, it's like reading a completely different language rather than C. <personal grouse>Effective as it is, why oh why isn't it at least indented properly. In this day an age when I routinely use a CLI window that has 160 characters of width and often push this to 200 when the need arises, why does everything have to be squashed up into the left-hand 50 chars? </personal grouse> I'm not sure that I'll be making any use of the information though. Once you see what is involved in an LVALUE perl> use Devel::Peek perl> $r = \substr('the quick brown fox', 10, 5) perl> print $r LVALUE(0x1bd2a70) perl> print $$r brown perl> Dump($r) SV = RV(0x1bd1cc0) at 0x1bd29f8 REFCNT = 1 FLAGS = (ROK) RV = 0x1bd2a70 SV = PVLV(0x1bc3388) at 0x1bd2a70 REFCNT = 1 FLAGS = (PADMY,GMG,SMG,pPOK) IV = 0 NV = 0 PV = 0x1bc37a8 "brown"\0 CUR = 5 LEN = 6 MAGIC = 0x1bc3338 MG_VIRTUAL = &PL_vtbl_substr MG_TYPE = 'x' TYPE = x TARGOFF = 10 TARGLEN = 5 TARG = 0x1bdf074 SV = PV(0x1bcd490) at 0x1bdf074 REFCNT = 1 FLAGS = (PADBUSY,POK,pPOK) PV = 0x1bc19f0 "the quick brown fox"\0 CUR = 19 LEN = 20 [download] you realise that LVALUE refs are far from the 'cheap' utility that they appeared (to me at least) to be. That combined with their undocumented nature probably outweights any advantages that they might have provided.	[reply] [d/l]
Re: Re: Re: LVALUE refs by xmath (Hermit) on Feb 16, 2003 at 19:56 UTC
ehm, Dump() just shows it all very verbosely.. but it IS a cheap utility. Cheaper than any alternative, at least. All you're seeing is that $x is a reference (RV 0x1bd1cc0) to the lvalue object (PVLV 0x1bc3388) which points to the string you've taken a substring of (PV 0x1bcd490), and the lvalue object has one piece of magic to point to the functions implementing extraction and replacement of substrings. That's obviously about as simple as it can get. Just for fun, dump an array containing the relevant info: `Dump [\'the quick brown fox', 10, 5];`	[reply] [d/l]


Pathologically Eclectic Rubbish Lister
	PerlMonks