Front page | perl.perl5.porters |
Postings from August 2021
Re: SV flags tidying
From: Dave Mitchell
August 7, 2021 11:39
Re: SV flags tidying
Message ID: YQ5w/mb+4GJIvLGR@iabyn.com
On Sat, Aug 07, 2021 at 01:50:05AM +0100, Paul "LeoNerd" Evans wrote:
> I've started a branch to tidy up some edges around the SvFLAGS
> So far I've:
> *) Created SVphv_HASAUX as an alias of SVf_OOK, so the flag/macro is
> named less confusingly there
> *) Renamed SVf_AMAGIC to SVphv_AMAGIC because it's only applied to
These might break some XS modules, but probably not many.
> I've also noticed that the SVp_SCREAM bit is currently not used on
> regular scalars except SvROK ones, and the SVf_IVisUV bit is only used
> on numerical (non-referential) scalars. I'm now testing a change to
> move that latter bit out from its own current position, into the same
> value as SVp_SCREAM. If this works, that will give us two spare free
> bits on regular scalars, conveniently right next to the SVf_UTF8 bit.
I don't understand how this gives you two spare bits. At most it should
give you one more for non-ref scalars. But bear in mind that SVf_IVisUV
can be set on a POK scalar. This:
my $x = 0xffffffffffffffff;
my $y = "$x";
SV = PVIV(0xdb0728) at 0xdafc68
REFCNT = 1
FLAGS = (IOK,POK,pIOK,pPOK,IsUV)
UV = 18446744073709551615
PV = 0xda2208 "18446744073709551615"\0
CUR = 20
LEN = 22
> We'll need two spare bits here if we want to track UNKNOWN|BYTES|TEXT
> state of strings.
If is a big word here.
> I imagine there probably isn't any compatibility problem with changing
> the value of a flag bit,
There's no problem changing the value of a flag, unless XS code is using
a "wrong" name for a flag. For example if a few years down the line XS
code is still testing for 'SVf_OOK' rather than 'SVphv_HASAUX' on hashes,
and we in the meantime stop them being synonyms and assign them different
values, then that XS will break.
> but perhaps to be on the safe side, if people
> think it best, I might give it new name while I'm moving it. Since it
> only applies (privately) to non-reference scalars, perhaps it should be
> called SVp_IVisUV instead?
Its not a private flag - its a public adjunct to the IOK flag to
distinguish signed from unsigned integers (normally only integers greater
in value than 0x7ff.....f get this flag set).
> It's possible that SVprv_WEAKREF will also get in the way here, and if
> so I may have to change its value too, but again the same compat
> questions apply.
Same answers apply.
"Foul and greedy Dwarf - you have eaten the last candle."
-- "Hordes of the Things", BBC Radio.