Front page | perl.perl5.porters |
Postings from December 2012
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.Thread Previous | Thread Next