Mercurial > hg > xemacs-beta
diff src/symbols.c @ 251:677f6a0ee643 r20-5b24
Import from CVS: tag r20-5b24
author | cvs |
---|---|
date | Mon, 13 Aug 2007 10:19:59 +0200 |
parents | e70b3a057e12 |
children | 966663fcf606 |
line wrap: on
line diff
--- a/src/symbols.c Mon Aug 13 10:19:12 2007 +0200 +++ b/src/symbols.c Mon Aug 13 10:19:59 2007 +0200 @@ -104,13 +104,7 @@ ((markobj) (sym->value)); ((markobj) (sym->function)); - /* DON'T mark through ->obarray slot. Since the slot is not visible - from Lisp, it would be wrong not to gc an obarray vector only - because there are symbols pointing to it. This is safe, because - we only check the nil-ness of the object. An implication of this - is that, when the obarray vector is gc-ed, its symbols are still - considered "interned" for printing purposes -- but it's probably - no big deal. */ + /* No need to mark through ->obarray, because it only holds nil or t. */ /*((markobj) (sym->obarray));*/ XSETSTRING (pname, sym->name); ((markobj) (pname)); @@ -201,7 +195,12 @@ if (purify_flag && ! purified (str)) str = make_pure_pname (XSTRING_DATA (str), len, 0); sym = Fmake_symbol (str); - XSYMBOL (sym)->obarray = obarray; + /* FSFmacs places OBARRAY here, but it is pointless because we do + not mark through this slot, so it is not usable later (because + the obarray might have been collected). Marking through the + ->obarray slot is an even worse idea, because it would keep + obarrays from being collected because of symbols pointed to them. */ + XSYMBOL (sym)->obarray = Qt; if (SYMBOLP (*ptr)) symbol_next (XSYMBOL (sym)) = XSYMBOL (*ptr); @@ -3174,7 +3173,7 @@ hash %= OBARRAY_SIZE; tem = &XVECTOR_DATA (Vobarray)[hash]; *tem = Qnil; - XSYMBOL (Qnil)->obarray = Vobarray; + XSYMBOL (Qnil)->obarray = Qt; } {