[Top][All Lists]

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

bug#11604: USE_LISP_UNION_TYPE + USE_LSB_TAG cleanup.

From: Eli Zaretskii
Subject: bug#11604: USE_LISP_UNION_TYPE + USE_LSB_TAG cleanup.
Date: Mon, 04 Jun 2012 16:38:38 +0300

> From: Stefan Monnier <address@hidden>
> Cc: Paul Eggert <address@hidden>,  address@hidden
> Date: Mon, 04 Jun 2012 09:12:23 -0400
> >> Because the union type is for debugging, not for production.
> > I didn't know that.  If that is so, it should be mentioned in the
> > comments somewhere.  (I actually thought that Stefan wants to move to
> > that model for production at some point, but maybe I misunderstood.)
> I'm not sure what it is you misunderstood, but I don't intend to use
> this "union type for Lisp_Object" for production.  I encourage
> people around here to use it, to catch errors a bit earlier

My misunderstanding, sorry.  I probably misinterpreted your

> such as myself is enough to get a pretty good code coverage), but it
> has too many downsides

OK, then I think we should just say in the comments that
USE_LISP_UNION_TYPE is for debugging and maintenance, and is not meant
to yield production grade code.

> (performance is one, 29bit ints vs 30bit ints is another)

If using USE_LISP_UNION_TYPE means EMACS_INT is one bit less wide,
then I guess w32heap.c is correct in testing both USE_LSB_TAG and
USE_LISP_UNION_TYPE, when it decides how much VM to reserve at

reply via email to

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