The UV version turns on IOK and *preserves* IsUV instead of turning on IOK and IsUV.
The other two don't preserve anything.
I don't know why the difference.
There is a SvIsUV_on(sv) that would have done the trick. Keep in mind that your original approach didn't converting the scalar to one that supports IVs (if possible) and you didn't handle magic. If it's just an internal scalar, you could get away with not doing those, though.
| [reply]
[d/l] |
There is a SvIsUV_on(sv)
Not in the docs I'm looking at. Where did you dig that one up from?
and you didn't handle magic. If it's just an internal scalar, you could get away with not doing those,
No, I never handle magic. It's not laziness but a design choice. The reason I drop into XS/I::C is for performance. There is no point in doing that if you then allow people to pass you arrays that are tied to disk, or scalars that use post-its as backing store :)
IMO the way perl handles magic in-line, is all wrong anyway. It imposes huge costs for something that is actually quite a rare event. It ought to be possible to make a single determination at the top of a routine and defer to a separate routine that handles magic when needed, thus leaving the main-line code free of such considerations. But that's another wish list item that it's far too late to consider at this point.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
It ought to be possible to make a single determination at the top of a routine
That is how it's done. A single SvGETMAGIC if you read a scalar, no matter how many times you read it. A single SvSETMAGIC if you write to a scalar, no matter how many times you write to it. You don't want to call magic twice, and not just for performance reasons.
| [reply] |
