Re^2: Reverting the internals of an IV to their original states

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
[download]

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
[download]

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

Comment on Re^2: Reverting the internals of an IV to their original states Select or Download Code

Replies are listed 'Best First'.
Re^3: Reverting the internals of an IV to their original states by dave_the_m (Monsignor) on Dec 27, 2021 at 15:23 UTC
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]
Re^4: Reverting the internals of an IV to their original states by syphilis (Archbishop) on Dec 28, 2021 at 00:45 UTC
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]
Re^5: Reverting the internals of an IV to their original states by NERDVANA (Priest) on Dec 30, 2021 at 22:21 UTC
I think we're all aware of the problem with round-tripping JSON, where it decodes a JSON number as a scalar, then if you use a string operation on it (such as a regex) and write it back out, you get a string instead of a number. And I think we all agree that it's unfortunate, but just a part of the philosophical mismatch between Perl and JavaScript, and not really anything that can be "fixed". So, I would say that it is generally a problem to have any code that makes assumptions based on the corrent flags of a scalar. Ideally, you should change the XS code's API to expect a string or number rather than guessing, and let the user tell you which type it is. (and I realize this is generally hard for nested data structures.)	[reply]
Re^6: Reverting the internals of an IV to their original states by syphilis (Archbishop) on Dec 31, 2021 at 01:21 UTC
Re^5: Reverting the internals of an IV to their original states by Anonymous Monk on Dec 30, 2021 at 22:23 UTC
I think we're all aware of the problem with round-tripping JSON, where it decodes a JSON number as a scalar, then if you use a string operation on it (such as a regex) and write it back out, you get a string instead of a number. And I think we all agree that it's unfortunate, but just a part of the philosophical mismatch between Perl and JavaScript, and not really anything that can be "fixed". So, I would say that it is generally a problem to have any code that makes assumptions based on the corrent flags of a scalar. Ideally, you should change the XS code's API to expect a string or number rather than guessing, and let the user tell you which type it is. (and I realize this is generally hard for nested data structures.)	[reply]