[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: & requires l-value

From: Ken Raeburn
Subject: Re: & requires l-value
Date: Tue, 21 May 2002 05:03:42 -0400
User-agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu)

Juanma Barranquero <address@hidden> writes:
> Perhaps the problem is related to recent changes by Ken Raeburn?

Yes.  With my changes to buffer.c, the UNIX/X11 code (the only part I
can test) seems to be good about treating the car/cdr slots as
read-only except in alloc.c (creation and GC) and certain macros in
lisp.h (setcar/setcdr).  This is one step in isolating the Lisp engine
implementation from the rest of the Emacs code, making modification of
that Lisp engine (such as changing object representations or GC
strategies) more practical.

We want the capability of implementing write barriers when an object
is modified, so object fields should not be written except through a
clearly defined set of macros or functions where the write barrier can
be implemented.

Miles Bader <address@hidden> writes:
> I guess it could use XCDR_AS_LVALUE instead of XCDR.

It could, but that would be counterproductive in the long run.

Undoing my change to LISP_MAKE_RVALUE would make things build again on
Windows, but if that's done, *please* make it conditionalized for
Windows, and commented as a temporary workaround until the Windows
code is fixed.  And maybe make the change in w32fns.c instead of
lisp.h.  I don't recommend any of this though.

> That code seems kind of dodgy to me though; it seems cleaner to just
> make the `tail' field in enumfont_t a normal Lisp_Object that points to
> either Qnil or a cons cell, and do the list splicing doing XSETCDR (it
> has a pointer to the head of the list anyway, so the nil case isn't a
> problem).

This is the better approach, even though it requires a little work.
Much like the changes I had to make in buffer.c -- which were a bit
more tedious, perhaps, since three list-element pointers were being
juggled at once.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]