Re: Reördering SVt_* constants; "internal" SV type

[email protected] ("H.Merijn Brand" via perl5-porters) Thu, 18 Jun 2026 14:45:20 +0200
Newsgroups	perl.perl5.porters
Message-ID	<20260618144422.44097d9e@pc09>
On Thu, 18 Jun 2026 12:43:25 +0100, "Paul \"LeoNerd\" Evans" <[email protected]> wrote:

> (By the way, we currently have 56 different PRs marked
> "defer-next-dev", awaiting the 5.44 release, and I'm still in the
> process of making the problem worse. ;) Anyhow...)
> 
> I have a few separate branches and items of work that all seem to be
> hitting upon a common problem. Namely, that I would like it if certain
> properties about SVs could be easily determined by a cheap number
> comparison on SvTYPE. In particular, I would really like it if we could
> write out comparisons in the following forms:
> 
>   An SV should be treated as a Perl-visible scalar
>     if SvTYPE(sv) <= SVt_PVMG
> 
>   An SV is a safe for Perl code to operate on
>     if SvTYPE(sv) <= some-other-value  (which would exclude a few weird
>                                        oddballs)
> 
> However, these comparisons don't work due to two annoying values that
> are apparently in the wrong place in the order; and thus we can't make
> a simple numerical comparison on a contiguous range.
> 
>   SVt_INVLIST   is not a perl-visible scalar, in fact should not be
>                 visible to any perl code anywhere for any reason, but
>                 it sorts right after SVt_PV and before SVt_PVIV and is
>                 thus accidentally included in the above scalar test
> 
>   SVt_PVLV      should be treated like a perl scalar with lvalue
>                 side-effects, but its value is listed after SVt_REGEXP
>                 and SVt_PVGV, which aren't really regular scalar values

I am scared it would break a lot of CPAN/XS

Only reporting the relational usages found in my devel env (and filtering ppport.h)

DBD-Oracle 🐧 grep -w SvTYPE  Oracle.xsi dbdimp.c oci8.c Oracle.xs
Oracle.xsi:    if (!SvROK(value_ref) || SvTYPE(SvRV(value_ref)) > SVt_PVMG)
dbdimp.c:            if(SvTYPE(shared_sv) < SVt_PVMG ||
dbdimp.c:       if (SvTYPE(newvalue) > SVt_PVAV) /* Array binding supported */

DBI 509 🐧 grep -w SvTYPE DBIXS.h Perl.c Driver.xst Driver_xst.h DBI.xs Perl.xsi
Perl.c:    if (!SvROK(value_ref) || SvTYPE(SvRV(value_ref)) > SVt_PVMG)
Driver.xst:    if (!SvROK(value_ref) || SvTYPE(SvRV(value_ref)) > SVt_PVMG)
DBI.xs:        if (SvTYPE(sv) >= SVt_PVAV)
DBI.xs:    if (!SvROK(ref) || SvTYPE(SvRV(ref)) > SVt_PVMG) /* XXX LV */
Perl.xsi:    if (!SvROK(value_ref) || SvTYPE(SvRV(value_ref)) > SVt_PVMG)

Cpanel-JSON-XS 🐧 grep -w SvTYPE XS.xs
XS.xs:               SvTYPE (SvRV (typesv)) < SVt_PVAV)
XS.xs:               SvTYPE (SvRV (typesv)) < SVt_PVAV)

Encode 🐧 grep -w SvTYPE Encode.xs
Encode.xs:    assert(SvTYPE(iv) >= SVt_PV); assert(SvLEN(iv) == 0);

There will be more

> I'd like to fix both of these problems.
> 
> I know there are some ordering constraints involved in the SvTYPE
> values, but I don't believe it would be too problematic to move
> SVt_PVLV to just after SVt_PVMG (and thus allow a contiguous range for
> scalars).
> 
> For various other work (e.g. making attributes lexically visible in the
> pad) I am working on adding an SV type for "things that need to be SVs
> for some reason, but definitely shouldn't be Perl-visible values". I'm
> designing it specifically so that INVLISTs could be moved to part of
> that rather than needing their own SV type. While I'm at it, I'd ensure
> that this new SVt_INTERNAL type definitely lives at the very end of the
> list, keeping it out of numerical range tests on most of the other
> sensible properties.
> 
> Can anyone foresee any problems with this as an overall plan? I intend
> to put it together soon so it can be used by my attributes-v2 branch,
> as well as for the bugfix for https://github.com/Perl/perl5/issues/24470
> 


-- 
H.Merijn Brand  https://tux.nl   Perl Monger   http://amsterdam.pm.org/
using perl5.00307 .. 5.37        porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
signature.asc (application/pgp-signature, 488 B)