X-Git-Url: https://git.distorted.org.uk/~mdw/sod/blobdiff_plain/9a9a7b35fe696f7dfe041935bf41e89558930aee..74bf1b29b8cef573908180e6ab00cfeb6f324b46:/doc/structures.tex

diff --git a/doc/structures.tex b/doc/structures.tex
index 7121692..37ca9e3 100644
--- a/doc/structures.tex
+++ b/doc/structures.tex
@@ -410,7 +410,7 @@ and this is followed by corresponding members
 \end{prog}
 for each of $C$'s superclasses $A$ in the same chain in some (unimportant)
 order.  The (somewhat obtuse) purpose of this union is to engage the `common
-initial sequence' rule of \cite[6.5.2.3]{FIXME:C99}.
+initial sequence' rule of \cite[6.5.2.3]{ISO:1990:IIP,ANSI:1999:AII}.
 
 \subsubsection{The ichain structure}
 The @|ichain| structure contains (in order), a pointer
@@ -450,9 +450,9 @@ superclass in the same chain, and each slot must be stored in exactly one
 place.  The layout of vtables doesn't have this second requirement: it
 doesn't matter that there are multiple method entry pointers for the same
 effective method as long as they all work correctly.  Indeed, it's essential
-that they do, because each chain's method entry function will need to apply a
-different offset to the receiver pointer before invoking the effective
-method.
+that there are multiple entry pointers, because each chain's method entry
+function will need to apply a different offset to the receiver pointer before
+invoking the effective method.
 
 A vtable for a class $C$ with chain head $H$ has the following general
 structure.
@@ -489,9 +489,9 @@ first.
 
 This is mostly an irrelevant detail, whose purpose is to defend against
 malicious compilers: pointers are always to one of the inner @|vt|
-structures. It's important only because it's the outer @|vtu| union which is
-exported by name. Specifically, for each chain of $C$'s superclasses there is
-an external object
+structures.  It's important only because it's the outer @|vtu| union which is
+exported by name.  Specifically, for each chain of $C$'s superclasses there
+is an external object
 \begin{prog}
   const union $A$__vtu_$i$ $C$__vtable_$i$;
 \end{prog}
@@ -637,13 +637,22 @@ defined for the sake of completeness.
 Finally, the class object is defined as
 \begin{prog}
   extern const struct $R$__ilayout $C$__classobj;               \\
-  \#define $C$__class (\&$C$__classobj.$j$.$r$)
+  \#define $C$__class (\&$C$__classobj.$j$.$r$)                 \\
+  \#define $C$__cls_$k$ (\&$C$__classobj.$k$.$n$)               \\
+  \quad$\vdots$
 \end{prog}
 The exported symbol @|$C$__classobj| contains the entire class instance.
 This is usually rather unwieldy.  The macro @|$C$__class| is usable as a
 pointer of type @|const $R$~*|, where $R$ is the root metaclass of $C$, i.e.,
 the metaclass of the least specific superclass of $C$; usually this is
-@|const SodClass~*|.
+@|const SodClass~*|.  For each chain of $C$'s metaclass, a macro
+@|$C$__cls_$k$| is defined, usable as a pointer of type @|const $N$~*|, where
+$K$ and $N$ are the chain's head and tail classes (i.e., the least- and
+most-specific classes in the chain) respectively; this macro is
+\emph{omitted} if $N = R$, i.e., in the common case where $C$'s metaclass is
+precisely the root metaclass, since the existing @|$C$__class| macro is
+already sufficient.
+
 
 %%%----- That's all, folks --------------------------------------------------
 
