summaryrefslogtreecommitdiff
path: root/internals
diff options
context:
space:
mode:
Diffstat (limited to 'internals')
-rw-r--r--internals32
1 files changed, 29 insertions, 3 deletions
diff --git a/internals b/internals
index 471ad95c08..fbf686e0c1 100644
--- a/internals
+++ b/internals
@@ -34,6 +34,8 @@ article, I can and probably should relax that. That code is some of
the oldest Perl 5 code, and I didn't see some things then that I do
now.
+[I did relax that.]
+
Ok, let me explain some things about how values are stored. Consider
this a little design document.
@@ -55,6 +57,8 @@ struct sv {
U8 sv_private; /* extra value, depending on type */
};
+[The last 4 bytes have been combined into a single U32.]
+
This is typedefed to SV. There are other structurally equivalent
types, AV, HV and CV, that are there merely to help gdb know what kind
of pointer sv_any is, and provide a little bit of C type-checking.
@@ -70,6 +74,7 @@ Additionally I often use names containing
IV integer value
NV numeric value (double)
PV pointer value
+ RV reference value
LV lvalue, such as a substr() or vec() being assigned to
BM a string containing a Boyer-Moore compiled pattern
FM a format line program
@@ -95,6 +100,9 @@ typedef enum {
SVt_PVFM,
} svtype;
+[There is no longer a REF type. There's an RV type that holds a minimal ref
+value but other types can also hold an RV. This was to allow magical refs.]
+
These are arranged ROUGHLY in order of increasing complexity, though
there are some discontinuities. Many of them indicate that sv_any
points to a struct of a similar name with an X on the front. They can
@@ -105,7 +113,8 @@ be classified like this:
SVt_REF
The sv_any points to another SV. (This is what we're talking
- about changing to work more like IV and NV below.)
+ about changing to work more like IV and NV below.) [And that's what
+ I did.]
SVt_IV
SVt_NV
@@ -120,6 +129,7 @@ be classified like this:
memory. This does waste a few allocated integers(doubles) at
the beginning, but it's probably an overall win.
+ [SVt_RV probably belongs here.]
SVt_PV
SVt_PVIV
SVt_PVNV
@@ -127,6 +137,15 @@ be classified like this:
These are pretty ordinary, and each is "derived" from the
previous in the sense that it just adds more data to the
previous structure.
+[ Need to add this:
+ struct xrv {
+ SV * xrv_rv; /* pointer to another SV */
+ };
+
+ A reference value. In the following structs its space is reserved
+ as a char* xpv_pv, but if SvROK() is true, xpv_pv is pointing to
+ another SV, not a string.
+]
struct xpv {
char * xpv_pv; /* pointer to malloced string */
@@ -187,23 +206,30 @@ be classified like this:
These are specialized forms that are never directly visible to
the Perl script. They are independent of each other, and may
not be promoted to any other type.
+ [Actually, PVBM doesn't belong here, but in the previous section.
+ saying index($foo,$bar) will in fact turn $bar into a PVBM so that
+ it can do Boyer-Moore searching.]
There are several additional data values in the SV structure. The sv_refcnt
gives the number of references to this SV. Some of these references may be
actual Perl language references, but many other are just internal pointers,
from a symbol table, or from the syntax tree, for example. When sv_refcnt
-goes to zero, the value can be safely deallocated.
+goes to zero, the value can be safely deallocated. Must be, in fact.
The sv_storage byte is not very well thought out, but tends to indicate
something about where the scalar lives. It's used in allocating
lexical storage, and at runtime contains an 'O' if the value has been
blessed as an object. There may be some conflicts lurking in here, and
-I may eventually claim some of the bits for other purposes.
+I may eventually claim some of the bits for other purposes. [I did,
+with a vengeance.]
The sv_flags are currently as follows. Most of these are set and cleared
by macros to guarantee their consistency, and you should always use the
proper macro rather than accessing them directly.
+[Most of these numbers have changed, and there are some new flags.
+And they're all stuffed into a single U32.]
+
#define SVf_IOK 1 /* has valid integer value */
#define SVf_NOK 2 /* has valid numeric value */
#define SVf_POK 4 /* has valid pointer value */