Front page | perl.perl5.porters |
Postings from January 2013
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)
as
#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 http://www.nntp.perl.org/group/perl.perl5.porters/2012/02/msg183615.html
>
> "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) { ... }
and
if(cBOOL(SvUOK)) { ... }
and see if the second is less efficient.
--
Never work with children, animals, or actors.
Thread Previous
|
Thread Next