Yitzchak Scott-Thoennes wrote:
Original problem: 'print ~v0' deparses as 'print v0', not 'print "\377"'.
Wow, a blast from the past (everyone else should note that this thread is over
three years old)...
What other things use the mg_ptr representation?
Don't know. The topic is discussed in perlguts and the mg_ptr is specifically
mentioned as a way for magical SV's to carry around a char * that means
something in the context of that kind of magic. However, I don't think that
most of the Perl code recognizes that a simple scalar (i.e. not a tied hash
element or some such) might be magical in this way, and hence assumes it can
just stomp on the existing slots with impunity. The problem only shows up when
some other code, like B::Deparse, tries to peek at the magic bits out of turn.
Where would you clear the V magic? The problem code in pp_complement
does a sv_setsv into the TARG then a SvPV_force, instead of just a
sv_setpvn into TARG. Doing an sv_setpvn fixes the bug, and is a
better representation of what the code is trying to actually do (copy
the pv into another sv, then modify it), but may lose the chance to
steal the pv?
Ah, I missed that subtly the last time I looked at this. pp_complement is being
somewhat naughty by assuming that the SV isn't ever going to be magical (or at
least, it handles get magic but not set magic). This is all for some
questionable performance gain (i.e. reusing the pv slot in the SV).
Other places that do sv_setsv*/SvPV_force/modify PV contents would also
have this problem. A quick look finds this deparses wrongly too:

"print -v45.48" deparses as "print v45.48", not "print '+0'".
I'm guessing that the other unary operators are likely to suffer from the same
premature optimization. I don't know how to fix this in the general case or
even if it desireable.

I think the specific case of B::Deparse is to stop it from using the original
string representation out of magic v-strings, and go back to assuming that the
v-string parsing is lossy (which is why I made them magic in the first place).
Or, B::Deparse could specifically try and use toke.c:scan_vstring to test
whether the pv slot is the same as when the v-string was created, and throw a
warning otherwise.

Look at it this way, before I introduced magic v-strings, it was totally
impossible to correctly deparse _anything_ that was in v-string notation. Your
choice now is to either accept that sometimes the deparse will be inaccurate either:

1) by using the mg_ptr to recover the original representation, and not noticing
that the scalar was modified post creation;

2) or by ignoring the magic v-string representation and never being able to
deparse it to anything as written (i.e. the case before magic v-strings were

I think that over all, the situation in #1 (the current state) is preferable to
losing any hope of deparsing the code accurately.

I think I tried to make magic v-strings readonly, but it broke things. Besides,
that horse is not only out of the barn, it has had multiple foals... ;-)


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 7 | next ›
Discussion Overview
groupperl5-porters @
postedJul 25, '07 at 8:11p
activeDec 23, '11 at 10:47p



site design / logo © 2019 Grokbase