On Tue, Jul 05, 2005 at 10:36:58AM -0400, George Schlossnagle wrote: > I'm working on a rather large XS project, and I have this weird SV > that I'm seeing: > > SV PVMG(0xab0cca0) at 0xab12fd4 > REFCNT = 2 > FLAGS = (TEMP,POK,pPOK) > IV = 0 > NV = 0 > PV = 0xab0c170 "This is the column's deck."\0 > CUR = 26 > LEN = 27 > > This looks weird to me because I see no magic tables and no stash. > It looks like it should just be a SvPV. Am I overlooking what magic > is attached to this guy?
No, it's completely sane. You don't need to have magic or a stash. > I don't have a small reproducing test case, and the setup to > replicate is a bit time consuming. I'm mainly looking for some > potential avenues to explore to explain the nature of this SV, and > not a complete solution. I suspect what has happened is that perl has re-used the same scalar that used to have magic. Because perl never (strictly nearly never) downgrades scalars, as soon as a particular scalar gets promoted as far as PVMG, then any other value assigned into it will leave it at PVMG. And if you copy that scalar above into another, the destination will be promoted to PVMG, even though it doesn't actually need to be. This is because the copy code promotes the destination based on the source scalar's type, before it looks into the source scalar to see how much data it's actually carrying. Given that the UTF8 code now uses magic to hold its offset cache, if you've used Unicode somewhere, or caused data to internally become encoded as UTF-8, then the scalar will be PVMG, even if the value it now holds is pure 7 bit ASCII now. Nicholas Clark
