If you're really bothered, make a temporary copy of the value, print using that, then free it
Yes, that's pretty much my goto approach when I have a sub that can potentially alter the flags of its arguments && I want to avoid doing so.
In some cases it can be a bit tedious, and I've often wondered whether it's feasible to instead just allow the flag alteration(s) to occur and then revert it/them. (Hence my question.)
For the demo case I provided, just calling SvPOK_off(sv); would be sufficient to restore the flags (as reported by Devel::Peek::Dump) to their original values.
That would then have $sv Dump()ing to:
SV = PVIV(0x33fea8) at 0x33d0e0
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 12345
PV = 0x2838458 "12345"\0
CUR = 5
LEN = 10
If the objective is to simply keep those flags unchanged, then that objective has now been met. But are there any gotchas associated with leaving $sv in that state ?
I'm not really all that bothered about flags being changed - except for when it happens without good reason.
As an example of flags being changed for no good reason, consider:
> perl -MStorable -MDevel::Peek -le "$v = 2**70; Dump($v); $f = Stora
+ble::freeze(\$v); Dump($v)"
SV = NV(0x47e370) at 0x47e388
REFCNT = 1
FLAGS = (NOK,pNOK)
NV = 1.18059162071741e+21
SV = PVNV(0x30a3e8) at 0x47e388
REFCNT = 1
FLAGS = (NOK,pIOK,pNOK,IsUV)
UV = 18446744073709551615
NV = 1.18059162071741e+21
PV = 0
I don't think we should assume that such an unannounced and unexpected alteration to the flags of $v would be of no consequence to the user.
Cheers,
Rob | [reply]
[d/l]
[select] |
Well the entire philosophy of the perl core for the last 25 years has been that whenever you want to access the value of an SV, you request the perl core to update that SV into the form you want, then access the appropriate slot for the value (the string or IV or whatever). For the vast majority of use cases this "just works". It's only a few edge cases (like data serialisers and bitwise operators) where this becomes an issue. Note that perl will only set the *private* versions of the flags if the conversion isn't fully accurate / reversible, such as the pIOK but not IOK in your example above.
This is very much tied to the perl language philosophy that values are type agnostic and the type of operation is specified by the operator, e.g. eq versus ==.
Although those flag changes are "unannounced", it's the sort of thing that happens to most SVs in most perl programs. I think you'd have to give a practical example of real harm being caused by these flag changes.
Dave.
| [reply] |
think you'd have to give a practical example of real harm being caused by these flag changes.
I don't have such an example.
I do note that, with the demo I provided, you'd be in for a nasty surprise if you omit the second Dump() and go on to pass the perl scalar to an XSub that acts differently when the IsUV flag is set.
But then, of course, that XSub should have been checking SvUOK(sv), not SvISUV(sv).
I do have XSubs that behave differently, based on the UV status. Luckily, they look at SvUOK(sv) and not SvIsUV(sv).
I think I'll restrict this notion of manually reverting flags "for emergency use only" - things like asteroid strikes, extreme geophysical disturbances, alien invasions, etc ;-)
Cheers,
Rob
| [reply] |
