[Perl/perl5] 20ae2c: Perl_newSVpvn_share now delegates checking for UTF...

[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: 20ae2cf70b6774fafe7da756793c26f9dd24337d
      https://github.com/Perl/perl5/commit/20ae2cf70b6774fafe7da756793c26f9dd24337d
  Author: Richard Leach <[email protected]>
  Date:   2026-03-30 (Mon, 30 Mar 2026)

  Changed paths:
    M sv.c

  Log Message:
  -----------
  Perl_newSVpvn_share now delegates checking for UTF-8 downgrade

This function used to call `utf8_to_bytes_temp_pv()` itself to downgrade
suitable UTF-8 strings prior to calling `sharepvn`. However, it did not
ensure that the `HVhek_WASUTF8` flag was set on the resulting HEK,
meaning that the relevant SVs returned by `keys()` did not have the
correct UTF-8 encoding.

`Perl_share_hek`, called via the `sharepvn` macro, also does a
`utf8_to_bytes_` pass of the string, but it does set the `HVhek_WASUTF8`
flag when necessary.

With this commit, `Perl_newSVpvn_flags` delegates the downgrade pass
to `Perl_share_hek` and then retrieves the UTF-8 and length detail
needed for the new SV from the resulting HEK.


  Commit: e965a79404498ccf00989b49bb71082101517173
      https://github.com/Perl/perl5/commit/e965a79404498ccf00989b49bb71082101517173
  Author: Richard Leach <[email protected]>
  Date:   2026-03-30 (Mon, 30 Mar 2026)

  Changed paths:
    M hv.c

  Log Message:
  -----------
  Perl_hv_common - retain HVhek_WASUTF8 flag in keysv HEKs

`Perl_hv_common` previously propagated the UTF-8 status of a `keysv`
already using a shared HEK, but not any `HVhek_WASUTF8` flag.
This flag indicates that the non-UTF-8 hash key originally had UTF-8
encoding and if converted back into a SV, such as via `keys()`, the
hash key should be converted back into UTF-8.

With this commit, `Perl_hv_common` now checks for both current and
original UTF-8 flags.


  Commit: 96754e667a0ed47621079de98d387d6d7d4f1f11
      https://github.com/Perl/perl5/commit/96754e667a0ed47621079de98d387d6d7d4f1f11
  Author: Richard Leach <[email protected]>
  Date:   2026-03-30 (Mon, 30 Mar 2026)

  Changed paths:
    M op.c
    M pp_hot.c

  Log Message:
  -----------
  Partially revert 70c62a0 workaround for loss of HVhek_WASUTF8 flag

The workarounds are no longer needed now that `Perl_newSVpvn_share` and
`Perl_hv_common` propagate the `HVhek_WASUTF8` flag.

The two new tests added in that previous commit are retained.


  Commit: 3bb3eb4fcab1b8077524e939d9f74155c9b11ba5
      https://github.com/Perl/perl5/commit/3bb3eb4fcab1b8077524e939d9f74155c9b11ba5
  Author: Richard Leach <[email protected]>
  Date:   2026-03-30 (Mon, 30 Mar 2026)

  Changed paths:
    M lib/B/Deparse.t
    M lib/builtin.t
    M op.c

  Log Message:
  -----------
  S_check_alt_hash_fields_hekify - hekified numbers retain valid IV/NVs

Where an OP_CONST SV that contains a number is hekified, the SV should
still retain the IV and/or NV value, the associated flags, and not
have the SVf_POK flag set if the SV did not originally contain a PV.

Doing so means that changes made to Deparse.t when
S_check_alt_hash_fields_hekify was added now need reverting. Those
Deparse.t tests, restored to their original state, reflect the
desired behaviour.

This commit addresses https://github.com/Perl/perl5/issues/24302


  Commit: 9c7db06a44208cd21c19a409eb7b0d5a7204c458
      https://github.com/Perl/perl5/commit/9c7db06a44208cd21c19a409eb7b0d5a7204c458
  Author: Richard Leach <[email protected]>
  Date:   2026-03-30 (Mon, 30 Mar 2026)

  Changed paths:
    M pod/perldelta.pod

  Log Message:
  -----------
  Perldelta for safer hekification of OP_CONST SVs


Compare: https://github.com/Perl/perl5/compare/c6c99e474158...9c7db06a4420

To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.