Re: Buffer-/frame-local variables [Was: Re: Make buffer- and frame-locals a misc object]

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>>> For 1), my previous (and inglorious) attempt to hack around
>>> save-excursion shows that mixing explicitly allocated/freed objects
>>> with GC-managed objects is poor idea, so getting rid of xmalloc/xfree
>>> makes the things more predictable.
>> Fear of the unknown is not a good motivation for a change ;-)
>> Have you found out what was the problem?
> The problem was that the marker embedded into struct Lisp_Excursion
> can be linked to buffer's undo list; when struct Lisp_Excursion gets
> xfree'd, the marker pointer from undo list becomes dangling.

So, the problem is not that the Lisp_Excursion used malloc/free, but
that the marker used malloc/free (implicitly by being embedded in the
Lisp_Excursion) although it can get captured by other pointers.

> OK. So please consider attached patch for the trunk.

See comments below.

>> I do wonder, tho: do we need those write-barriers in the object-creation
>> function (e.g. make_buffer_local_value)?
> In general, no, since all just allocated objects are new by definition,
> and write barrier action is raised only if the pointer to new object is
> stored into an old one. So, the write barrier is installed but never
> raised;

Another reason is that until they're initialized, the fields contain
invalid values, so if the GC sees them we're in trouble, right?

-	    valcontents = BLV_VALUE (blv);
+	    valcontents = XCDR (blv->valcell);

Please don't: BLV_VALUE is more clear and abstract (same applies to
other places where you replace BLV_VALUE with XCDR (blv->valcell)).

-#define BLV_FOUND(blv) \
+get_blv_found (struct Lisp_Buffer_Local_Value *blv)

Why add a "get_" prefix?
Elisp and Emacs generally uses "<type>-<field>" for accessors and
"set-<type>-<field>" for setters.


        Stefan