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 /av.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 'av.c')
0 files changed, 0 insertions, 0 deletions