& requires l-value

& requires l-value

[Juanma Barranquero]

I'm getting the following error while compiling on Windows with MSVC:

w32fns.c(7255) : error C2102: '&' requires l-value

The offending line is:

	  lpef->tail = &(XCDR (*lpef->tail));


Perhaps the problem is related to recent changes by Ken Raeburn?


                                                           /L/e/k/t/u

Re: & requires l-value

[Miles Bader]

Juanma Barranquero <lektu@terra.es> writes:
> I'm getting the following error while compiling on Windows with MSVC:
> 
> w32fns.c(7255) : error C2102: '&' requires l-value
> 
> The offending line is:
> 
> 	  lpef->tail = &(XCDR (*lpef->tail));

I guess it could use XCDR_AS_LVALUE instead of XCDR.

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).

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: & requires l-value

[Ken Raeburn]

Juanma Barranquero <lektu@terra.es> 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 <miles@lsi.nec.co.jp> 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.

Ken

Re: & requires l-value

[Miles Bader]

Ken Raeburn <raeburn@raeburn.org> writes:
> > 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.

It looks like _very_ little work, actually -- there's only two places
that actually seem to reference the `tail' field.

Morever, that seems to be the only place left in emacs that takes the
address of XCAR/XCDR, so I'd say it's well worth doing.  I'd do it,
since it's so easy, but perhaps it's better left to the w32 maintainer,
who can test it.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: & requires l-value

[Jason Rumney]

Ken Raeburn <raeburn@raeburn.org> 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.

Surely as a temporary workaround, XCDR_AS_LVALUE would be better than
backing out the LISP_MAKE_RVALUE changes, or am I missing something
else?

It might be a few days before I get time to fix this properly, so if
XCDR_AS_LVALUE is an acceptable temporary solution, could someone
please make that change so Windows users can build again (I won't be
able to make the change until at least tomorrow evening).

-- 
Jason Rumney <jasonr@gnu.org>

Re: & requires l-value

[Ken Raeburn]

Jason Rumney <jasonr@gnu.org> writes:
> Surely as a temporary workaround, XCDR_AS_LVALUE would be better than
> backing out the LISP_MAKE_RVALUE changes, or am I missing something
> else?

Yes, I suppose it would.  I guess I'm just reacting reflexively to
someone proposing use of something I intented to be "internal" to the
Lisp implementation.  Of course, hacking LISP_MAKE_RVALUE to disable
it has the same effect, but I had hacked it first :-).

> It might be a few days before I get time to fix this properly, so if
> XCDR_AS_LVALUE is an acceptable temporary solution, could someone
> please make that change so Windows users can build again (I won't be
> able to make the change until at least tomorrow evening).

Done.  Juanma, could you please test it?

Ken

Re: & requires l-value

[Juanma Barranquero]

On Tue, 21 May 2002 17:36:13 -0400, Ken Raeburn <raeburn@raeburn.org> wrote:

> Done.  Juanma, could you please test it?

Yes, it is working now.

Thanks,

                                                           /L/e/k/t/u