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

Re: I think b630937 (SvUOK docs) is wrong

Thread Previous | Thread Next
January 14, 2013 06:16
Re: I think b630937 (SvUOK docs) is wrong
Message ID:
Karl Williamson wrote:
> On 12/24/2012 10:26 PM, bulk88 wrote:
>> Karl Williamson wrote:
>>> I don't understand most of what you are saying.  I did this because I
>>> got burned.  In blead, doing a SvUOK(newSVuv(1)) returns FALSE.  That
>>> needs to be either changed or documented.  Investigation showed that
>>> it would return TRUE iff the value being stored won't fit in an IV.  I
>>> hoped that documenting it might cause people to question the current
>>> design.
>>> Patches or wording suggestions welcome.
>> My wording suggestion.
>> ___________________________________________________________
>> Returns a boolean indicating whether the SV contains an integer which
>> must be interpreted as unsigned. An integer whose value is within the
>> range of both an IV and an UV maybe be flagged as either.
> 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)

The other thing is, the flag checkers represent flags. Flags don't 
guarantee behavior or a statement of fact outright. Just because an SV 
is SVt_PVMG does not mean it is magical. 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'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.

XS code wise/back compat, IDK the implications. I would look at whether 
non 2s compliment platforms might have bugs come up (are there any? does 
Perl guarantee compatibility with non twos complement C compilers?). 
Someone (I think its unlikely, I am not going to grep cpan right now) 
might be using the UV flag on IV range integers as bit stealing to 
encode something.

>> ___________________________________________________________
>> Another note for nitpicking, none of the *OK macros return booleans (1
>> or 0). They return 0 or not 0.  I don't want to say true/false either
>> since that means something else in C++. Not sure if its worth correcting
>> the "boolean" word or not, or its obvious that you will learn very quick
>> to not compare it to 1.
> I looked at the code, and the macros I saw returned the result of a 
> logical expression, which according to K&R is 0 or 1.  Does your 
> compiler not follow that?   

My mistake, most (not all) of the *OK macros don't return booleans.
   ((svSvNIOK)->sv_flags & (0x00000100|0x00000200));
   ((svSvIOK)->sv_flags & 0x00000100);
   ((svSvIsUV)->sv_flags & 0x80000000);

I wrote that sentence generically.

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