Front page | perl.perl5.porters |
Postings from January 2013
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 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. 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. ___________________________________________ SvNIOK(svSvNIOK); SvIOK(svSvIOK); SvIsUV(svSvIsUV); ___________________________________________ becomes ___________________________________________ ((svSvNIOK)->sv_flags & (0x00000100|0x00000200)); ((svSvIOK)->sv_flags & 0x00000100); ((svSvIsUV)->sv_flags & 0x80000000); ___________________________________________ I wrote that sentence generically.Thread Previous | Thread Next