sv.h: add some more flag usage commentary
authorDavid Mitchell <davem@iabyn.com>
Fri, 7 Mar 2014 17:13:07 +0000 (17:13 +0000)
committerDavid Mitchell <davem@iabyn.com>
Fri, 7 Mar 2014 17:13:07 +0000 (17:13 +0000)
Also, move SVphv_SHAREKEYS up to be closer to SVf_UTF8 - they are the same
flag bit, but it wasn't clear, since there was a big gap between them

sv.h

diff --git a/sv.h b/sv.h
index a54fd8f..396a36b 100644 (file)
--- a/sv.h
+++ b/sv.h
@@ -405,21 +405,24 @@ perform the upgrade if necessary.  See C<svtype>.
 
 #define SVf_AMAGIC     0x10000000  /* has magical overloaded methods */
 
+/* note that SVf_AMAGIC is now only set on stashes, so this bit is free
+ * for non-HV SVs */
+
 /* Ensure this value does not clash with the GV_ADD* flags in gv.h: */
 #define SVf_UTF8        0x20000000  /* SvPV is UTF-8 encoded
                                       This is also set on RVs whose overloaded
                                       stringification is UTF-8. This might
                                       only happen as a side effect of SvPV() */
-                                          
-
-/* Some private flags. */
+/* PVHV */
+#define SVphv_SHAREKEYS 0x20000000  /* PVHV keys live on shared string table */
 
 /* PVAV could probably use 0x2000000 without conflict. I assume that PVFM can
    be UTF-8 encoded, and PVCVs could well have UTF-8 prototypes. PVIOs haven't
    been restructured, so sometimes get used as string buffers.  */
 
-/* PVHV */
-#define SVphv_SHAREKEYS 0x20000000  /* PVHV keys live on shared string table */
+
+/* Some private flags. */
+
 
 /* PVNV, PVMG only, and only used in pads. Should be safe to test on any scalar
    SV, as the core is careful to avoid setting both.