develooper Front page | perl.perl5.porters | Postings from January 2013

Re: I think b630937 (SvUOK docs) is wrong

Thread Previous | Thread Next
Dave Mitchell
January 14, 2013 16:46
Re: I think b630937 (SvUOK docs) is wrong
Message ID:
On Mon, Jan 14, 2013 at 01:15:20AM -0500, bulk88 wrote:
> >What would the implications be of changing the macro to match the
> >prior documentation, and return true if it is indeed SvIOK with a
> >positive number?
> Longer machine code to put a >/< in there. Currently it is
> _____________________________________________________________________
> #define SvIOK_UV(sv)		((SvFLAGS(sv) & (SVf_IOK|SVf_IVisUV))	\
> 				 == (SVf_IOK|SVf_IVisUV))
> #define SvUOK(sv)		SvIOK_UV(sv)
> _____________________________________________________________________

Normally we'd use cBOOL, which is defined (for maximum portability)

    #define cBOOL(cbool) ((cbool) ? (bool)1 : (bool)0)

> The other thing is, the flag checkers represent flags. Flags don't
> guarantee behavior or a statement of fact outright.

It depends.

> Just because an
> SV is SVt_PVMG does not mean it is magical.

No, because that's not a flag, its a container type (which is capable of
supporting, but may or may not, have magic).

> I *guess* just because a
> SV has SVs_GMG doesn't mean that xmg_u.xmg_magic is not NULL (not
> sure if such a SV is following the rules or not).

I would regard an SV with SVs_GMG but without xmg_u.xmg_magic as a bug.
S_sv_unmagicext_flags() explicitly clears the magic bits if there's no
magic left.

> I'll quote
> "Hence I don't think that "expanding"
> SvOK_off() is the way to go, as it's *supposed* to be flag manipulation
> macro, not a function with side effects.
> "
> Adding a gt/lt to SvUOK would mean it stops being purely flag manipulation.

Its not a flag *manipulation* macro, its a flag *testing* macro,
documented to return a boolean value indicating whether a particular state
(usually a combination of flag bits, but sometimes other things too) is
true. So returning a boolean value is the right thing to do, modulo
performance and back-compat concerns.

I'd suggest waiting till after 5.18 is out, then change them and see what
breaks. (That gives us a whole year to find out).

It would also be good if someone could compare the assembly produced by say

    if(SvUOK) { ... }


    if(cBOOL(SvUOK)) { ... }

and see if the second is less efficient.

Never work with children, animals, or actors.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About