Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

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

by dave_the_m (Monsignor)
on Dec 27, 2021 at 10:31 UTC ( [id://11139934] : note . print w/replies, xml ) Need Help??


in reply to Reverting the internals of an IV to their original states

In general, perl doesn't have APIs to downgrade SVs. If you're really bothered, make a temporary copy of the value, print using that, then free it. By the way, your code with the SvPV_set() will leak the string buffer each time.

Dave.

  • Comment on Re: Reverting the internals of an IV to their original states

Replies are listed 'Best First'.
Re^2: Reverting the internals of an IV to their original states
by syphilis (Archbishop) on Dec 27, 2021 at 14:15 UTC
    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
      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.

        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