develooper Front page | perl.perl5.porters | Postings from August 2021

Re: SV flags tidying

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
August 7, 2021 11:39
Subject:
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
> constants.
> 
>   https://github.com/leonerd/perl5/tree/sv-flags-tidy
> 
> 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
>      stashes

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:

    use Devel::Peek;
    my $x = 0xffffffffffffffff;
    my $y = "$x";
    Dump $x;

gives:

    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.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About