>>>> "GIN" == Golubev I N <gin(a)mo.msk.ru>
> Lisp_Subr.doc could be a Lisp string or an
> integer, or perhaps nil, meaning we have to read in the doc file.
The correct design for Lisp_Subr is as follows:
The `doc' member should be removed from Lisp_Subr. This allows
Lisp_Subr's to be declared const and put into the rodata section.
The dumped executable should have no docstrings in it. The first time
a user invokes a documentation function, the DOC file is (lazily) read, and
documentation strings (or pointers to same) are snarfed into XEmacs.
The doc pointers should be in a separate C-visible object, probably a
hash table. This allows eliminating the weird int/string doc hack.
GIN> A kludge to avoid GC may be suggested. `doc' is declared as
GIN> Lisp_Object, but never traversed during GC. When INTP(doc),
GIN> XUINT(doc) is offset in `DOC' file. When (XTYPE(doc) ==
GIN> Lisp_Type_Record), (char*)XPNTRVAL(doc) points to actual (malloced)
GIN> string. We still reuse a way to store pointer and integer
GIN> distinguishably, and get adjustment to new architecture automatically
GIN> once we have adjusted Lisp_Object representation to it.
You are right that the docstring should be immune from garbage
collection. Since Lisp_Subr's are permanent objects, their
corresponding docstrings can be as well. It's tricky to implement
this efficiently and cleanly.
> For example, XEmacs assumes the lowest two bits
> of every pointer are always zero.
GIN> This is also the case for pointers returned by `malloc', which are
GIN> currently used as values for doc strings.