>>>> "GIN" == Golubev I N <gin(a)mo.msk.ru>
GIN> It works this way (doc.c): doc type is (char *). If (EMACS_INT) doc >=
GIN> 0, it is really a pointer. Otherwise we should use (off_t) (-
GIN> (EMACS_INT) doc) for seeking in `DOC' file.
GIN> It used to be this way in emacs-18.55, so it worked for all known
GIN> platforms for more than 10 yrs, and my ones are no exception. But
GIN> what forbids it to stop working? What requires valid pointers to be
GIN> non- negative when converted to integer? Once it is not the case, doc
GIN> implementation has to be rewritten.
On all current XEmacs platforms,
sizeof (void *) == sizeof (EMACSINT)
and XEmacs often treats pointers as non-opaque objects by
bit-twiddling them. For example, XEmacs assumes the lowest two bits
of every pointer are always zero.
GIN> Most surprising is why design its own representation rules for doc?
GIN> We just have a way to store both integer and pointer in a single word
GIN> distinguishably: Lisp_Object. Why not reuse it for Lisp_Subr.doc?
That's a good point. Lisp_Subr.doc could be a Lisp string or an
integer, or perhaps nil, meaning we have to read in the doc file.
The disadvantage is that whenever we have more Lisp objects, we have
longer garbage collection times. XEmacs developers have not been as
parsimonious in creating new Lisp objects as they could be, and we
don't yet have an incremental GC.