documenting SVf_PROTECT

FC,

does this commit of mine look correct?

commit cc25b9e2d291fedac80973dc493e321d31d3cb1a
Author:     David Mitchell <davem@iabyn.com>
AuthorDate: Thu Nov 24 14:42:27 2016 +0000
Commit:     David Mitchell <davem@iabyn.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 ...
    M	sv.h

Differences ...

diff --git a/sv.h b/sv.h
index 7808b89..ee65879 100644
--- a/sv.h
+++ b/sv.h
@@ -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).

• documenting SVf_PROTECT by Dave Mitchell
• Re: documenting SVf_PROTECT by Father Chrysostomos