[Perl/perl5] e75458: S_newSVsv_flags_NN_PVxx - ensure that xiv_u and xn...
[email protected] (Richard Leach via perl5-changes)
| Newsgroups | perl.perl5.changes |
|---|---|
| Message-ID | <Perl/perl5/push/refs/heads/blead/[email protected]> |
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: e754582d735a91352151aa27efb79f25101b7e16
https://github.com/Perl/perl5/commit/e754582d735a91352151aa27efb79f25101b7e16
Author: Richard Leach <[email protected]>
Date: 2026-03-10 (Tue, 10 Mar 2026)
Changed paths:
M sv.c
M t/op/svflags.t
Log Message:
-----------
S_newSVsv_flags_NN_PVxx - ensure that xiv_u and xnv_u are initialized
When added earlier in this development cycle, `S_newSVsv_flags_NN_PVxx`
would only initialize `xiv_u` and `xnv_u` struct members in PVIV, PVNV,
and PVMG types if the relevant `IOK` or `NOK` flags were set. Since the
absence of flags technically means that the contents of these struct
members are not valid for use, skipping initialization seemed like a
way of reducing unnecessary memory store operations.
GH#24242 revealed that `PL_linestr` in _toke.c_ breaks that assumption.
`PL_linestr` behaves as an IV/PV dualvar, but is only `SvPOK` not `SvIOK`.
Given that there is a reasonable chance that this is not the only code
with that kind of behaviour, this commit adds additional initialization
to the branches that would otherwise have left `xiv_u` and/or `xnv_u`
uninitialized.
To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications