|
From: | Paul Eggert |
Subject: | Re: USE_LSB_TAG not supported on this platform |
Date: | Sat, 6 Feb 2016 12:34:40 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
Herbert J. Skuhra wrote:
INTPTR_MAX=0x7fffffff EMACS_INT_MAX=0x7fffffffffffffffLL Before the commit mentioned above both are 0x7fffffff.
Commit d6585a910ed3e9e0e43c093b5fbfeb6d56b703b4 should not have affected EMACS_INT_MAX, and I don't see how it did.
I assume you are not configuring with --with-wide-int, so the reason EMACS_INT_MAX has that large value is due to the following tests in src/lisp.h:
# if INTPTR_MAX <= 0 # error "INTPTR_MAX misconfigured" # elif INTPTR_MAX <= INT_MAX >> NONPOINTER_BITS && !defined WIDE_EMACS_INT ... # elif INTPTR_MAX <= LONG_MAX >> NONPOINTER_BITS && !defined WIDE_EMACS_INT ... # elif INTPTR_MAX <= LLONG_MAX ... # define EMACS_INT_MAX LLONG_MAX #endifIs the value of NONPOINTER_BITS 0 on your platform, or 3? If 0, is this correct? That is, does malloc ever return a pointer that, when treated as an integer, is not a multiple of 8? If malloc always returns a multiple of 8, then we should be able to work around the problem by setting NONPOINTER_BITS to 0 on your platform.
[Prev in Thread] | Current Thread | [Next in Thread] |