Front page | perl.perl5.porters |
Postings from December 2012
On 12/24/2012 07:15 PM, bulk88 wrote: > Father Chrysostomos wrote: >> I think b630937 (SvUOK docs) is wrong >> >> I find this commit questionable: >> >> From b630937b8bf49e835d8976fc1036e68c79585b04 Mon Sep 17 00:00:00 2001 >> From: Karl Williamson <public@khwilliamson.com> >> Date: Mon, 24 Dec 2012 08:39:58 -0700 >> Subject: [PATCH] perlapi: Fix misstatement >> >> According to the comments for Perl_sv_setuv(), for performance reasons, >> a UV that fits in an IV is stored as an IV. >> --- >> sv.h | 6 ++++-- >> 1 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/sv.h b/sv.h >> index b841464..f01a91c 100644 >> --- a/sv.h >> +++ b/sv.h >> @@ -655,10 +655,12 @@ Tells an SV that it is an integer and disables >> all other OK bits. >> Tells an SV that it is an unsigned integer and disables all other OK >> bits. >> >> =for apidoc Am|bool|SvIOK_UV|SV* sv >> -Returns a boolean indicating whether the SV contains an unsigned >> integer. >> +Returns a boolean indicating whether the SV contains an unsigned integer >> +that is too large to store as an IV. >> >> =for apidoc Am|bool|SvUOK|SV* sv >> -Returns a boolean indicating whether the SV contains an unsigned >> integer. >> +Returns a boolean indicating whether the SV contains an unsigned integer >> +that is too large to store as an IV. >> >> =for apidoc Am|bool|SvIOK_notUV|SV* sv >> Returns a boolean indicating whether the SV contains a signed integer. > > The "for performance reasons" might be removed in the future if someone > does research and sees its not beneficial for some reason or another. It > might also be changed for CPU-specific reasons. That detail should not > be codified. Non core XS code might not follow that rule (a UV in range > of an IV is stored as an IV) when creating a UV without sv_setuv. > 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.Thread Previous | Thread Next