Re: subr doc representation

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. GIN> This is also the case for pointers returned by `malloc', which are GIN> currently used as values for doc strings.