diff options
author | David Mitchell <davem@iabyn.com> | 2016-01-19 15:19:48 +0000 |
---|---|---|
committer | David Mitchell <davem@iabyn.com> | 2016-01-19 15:19:48 +0000 |
commit | 3c84a230ed64f5ef68617ef355b5b35bf93a3951 (patch) | |
tree | 5f9c8b4bd197ff1c3f8731f3c5648177c9d6617c /sv.c | |
parent | 88e8953ab73a4d30082802322680035722e28de9 (diff) | |
download | perl-3c84a230ed64f5ef68617ef355b5b35bf93a3951.tar.gz |
remove vestigial uses of PRIVSHIFT
This is a hangover from when a magic (e.g. tied) var, after calling
mg_get(), would only set the private (SVp_IOK,SVp_NOK,SVp_POK)
flags on the result, indicating that although it now had a valid integer
value (say), it wasn't a "real" integer. This was achieved by, after
calling mg_get(), shifting all the public flags by PRIVSHIFT to convert
them to private flags.
Since 5.18.0, that's not been the case (i.e. mg_get() on a tied var leaves
Svf_IOK etc set). But there are still a couple of vestigial uses of
PRIVSHIFT in the core, and this commit removes them.
For one of them, I added a test that shows that (in slightly contrived
circumnstances), it was possible for a SVp_IOK NV to be upgraded
to a SVf_IOK int on return from localisation, losing its fractional
component.
The other one, in S_sv_unmagicext_flags(), only seemed to get called
when setting a new value (e.g. from mg_set()), so its unlikely that such a
var would still have private flags set that could be incorrectly upgraded
to public.
Diffstat (limited to 'sv.c')
-rw-r--r-- | sv.c | 5 |
1 files changed, 2 insertions, 3 deletions
@@ -5757,10 +5757,9 @@ S_sv_unmagicext_flags(pTHX_ SV *const sv, const int type, MGVTBL *vtbl, const U3 if (SvMAGICAL(sv)) /* if we're under save_magic, wait for restore_magic; */ mg_magical(sv); /* else fix the flags now */ } - else { + else SvMAGICAL_off(sv); - SvFLAGS(sv) |= (SvFLAGS(sv) & (SVp_IOK|SVp_NOK|SVp_POK)) >> PRIVSHIFT; - } + return 0; } |