From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [RFC perlmod] ffi glue: type detection: check actual SV flags instead of structural body type
Date: Fri, 27 Mar 2026 16:06:29 +0100 [thread overview]
Message-ID: <177462398929.480952.2396055683726895580.b4-review@b4> (raw)
In-Reply-To: <20260310204737.2475584-1-t.lamprecht@proxmox.com>
On Tue, 10 Mar 2026 21:45:43 +0100, Thomas Lamprecht <t.lamprecht@proxmox.com> wrote:
> RSPL_type_flags and the RSPL_has_* helpers used a lookup table indexed
> by SvTYPE, which reflects the structural body layout (what slots are
> allocated) rather than which slots hold valid data. Since SV body types
> only upgrade and never downgrade, this caused misclassification [0].
>
> For example, a string "65004" coerced to integer via int() still
> reported STRING|INTEGER|DOUBLE because SvTYPE remained SVt_PVNV. The
> deserializer then treated it as a string, and the SvPVutf8 call to
> read it set SVf_POK as a side effect, making the contamination
> permanent.
>
> Replace the table with actual per-slot validity checks using
> SvIOKp/SvNOKp/SvPOKp. The private "p" variants are needed because
> SvOK (used in RSPL_is_defined) also considers private flags -- using
> only the public variants can leave defined values with no type flags.
Doing
my $x = 3;
shows via Devel::Peek's Dump($x):
FLAGS = (IOK,pIOK)
and after doing
"stringify${x}"
or
$x ~= /./
it shows
FLAGS = (IOK,pIOK,pPOK)
indicating that *privately* it also has a string representation.
So IMO we could check public flags first, but then fall back to the old
code if they are empty for some reason?
--
prev parent reply other threads:[~2026-03-27 15:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 20:45 Thomas Lamprecht
2026-03-27 15:06 ` Wolfgang Bumiller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=177462398929.480952.2396055683726895580.b4-review@b4 \
--to=w.bumiller@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox