Re: XS: returning a 64-bit unsigned int?

[ikegami]

in reply to XS: returning a 64-bit unsigned int?

Which one of these is not like the other...

#define SvNOK_only(sv) \
    (SvOK_off(sv), SvFLAGS(sv) |= (SVf_NOK|SVp_NOK))

#define SvIOK_only(sv) \
    (SvOK_off(sv), SvFLAGS(sv) |= (SVf_IOK|SVp_IOK))

#define SvIOK_only_UV(sv) \
    (assert_not_glob(sv) \
    SvOK_off_exc_UV(sv), SvFLAGS(sv) |= (SVf_IOK|SVp_IOK))

[BrowserUk]

I can see the difference, but what it means I have no idea?

[ikegami]

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.

[BrowserUk]

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.