Re: subr doc representation

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.