Front page | perl.perl5.porters |
Postings from November 2016
From: Dave Mitchell
November 24, 2016 14:49
Message ID: 20161124144936.GF4785@iabyn.com
does this commit of mine look correct?
Author: David Mitchell <firstname.lastname@example.org>
AuthorDate: Thu Nov 24 14:42:27 2016 +0000
Commit: David Mitchell <email@example.com>
CommitDate: Thu Nov 24 14:42:27 2016 +0000
add comments explaining the point of SVf_PROTECT
The flag was added by v5.21.4-17-ga623f89, but outside of the commit
message itself, there didn't seem to be any explanation for this flag.
Affected files ...
diff --git a/sv.h b/sv.h
index 7808b89..ee65879 100644
@@ -374,6 +374,15 @@ perform the upgrade if necessary. See C<L</svtype>>.
subroutine in another package. Set the
GvIMPORTED_CV_on() if it needs to be
expanded to a real GV */
+/* SVf_PROTECT is what SVf_READONLY should have been: i.e. modifying
+ * this SV is completely illegal. However, SVf_READONLY (via
+ * Internals::SvREADONLY()) has come to be seen as a flag that can be
+ * temporarily set and unset by the user to indicate e.g. whether a hash
+ * is "locked". Now, Hash::Util et al only set SVf_READONLY, while core
+ * sets both (SVf_READONLY|SVf_PROTECT) to indicate both to core and user
+ * code that this SV should not be messed with.
#define SVf_PROTECT 0x00010000 /* very read-only */
#define SVs_PADTMP 0x00020000 /* in use as tmp */
#define SVs_PADSTALE 0x00040000 /* lexical has gone out of scope;
You live and learn (although usually you just live).
by Dave Mitchell