Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

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 ( [id://11139938] : note . print w/replies, xml ) Need Help??


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

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.

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

Replies are listed 'Best First'.
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
      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.)

        I think we're all aware of the problem with round-tripping JSON

        Yes, I've heard of it.
        I think this is a "data serialisers" issue that dave_the_m alluded to in his last post to this thread.
        There's an open perl issue about this, where changes to the way that perl's numeric flags are set/unset is being considered.
        I don't know what, if anything, will come of it ....

        Cheers,
        Rob
      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.)