This repository has been archived by the owner on Jun 1, 2023. It is now read-only.
Keep SPECIAL immortals in arrays, esp. YES, NO #413
Assignees
Labels
Comments
rurban
added a commit
that referenced
this issue
May 17, 2020
i.e. -e"print [!0]->[0]" See GH #413 Does not work ye
rurban
added a commit
that referenced
this issue
May 18, 2020
i.e. -e"print [!0]->[0]" See GH #413 Unfortunately we cannot fix the main culprit sv_setsv_flags, as we cannot set the pointer of dest, only the value. So we need to fix the callers. The SV values for arrays and hashes.
rurban
added a commit
that referenced
this issue
May 18, 2020
i.e. -e"print [!0]->[0]" See GH #413 Unfortunately we cannot fix the main culprit sv_setsv_flags, as we cannot set the pointer of dest, only the value. So we need to fix the callers. The SV values for arrays and hashes. Problem with this one: cperl -Dt -e'$a=[undef,undef];$a->[0]=1' (-e:0) enter (-e:0) nextstate (-e:1) pushmark (-e:1) undef (-e:1) undef (-e:1) anonlist (-e:1) gvsv(main::a) (-e:1) sassign (-e:1) nextstate (-e:1) const(IV(1)) (-e:1) multideref($a->[0]) (-e:1) sassign Modification of a read-only value attempted SV_UNDEF at sv.c:4283 at -e line 1. Apparently array elements need to be writable, immortals are forbidden. Which blows up memory for all arrays/sets of immortals (yes,no,undef). So allow writing to immortals in arrays/hashes, set the SPECIAL flag to sassign, as with const init: my $i:const = 1 The no modify warning is only to prevent undef=1 or yes=0, which is easier preventable.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The parser keeps SV_YES, SV_NO and friends in arrays asis. But when converting at runtime into a list, via av_make and sv_setsv the SV_YES is lost and turned into a PVNV of 1
Special case
sv_setsv_flagsfor the immortals (not possible, rather fix the callers), which also makes it faster for these. They don't need to be copied, they are immortal after all.See rurban/Cpanel-JSON-XS#161
This is esp. useful for XS roundtrips, treating booleans as such. Currently one needs to bless them into some magic Boolean package to survive roundtrips.
The text was updated successfully, but these errors were encountered: