SL Baur writes:
Hrvoje Niksic <hniksic(a)srce.hr> writes in
xemacs-beta(a)xemacs.org:
...
> Note that no editor on 32-bit systems can grok a >2G buffer because of
> limited pointer size. Thus a 1G limit is just one step below the
> "theoretical" limit. You can argue that being two steps below it is
> not much worse, but I am not really convinced.
O.K. Since size matters to you, how about another alternative? What
would/could we gain or lose by using long long as EMACS_INTs on 32 bit
architectures?
We don't really have to use long long, we can mandate use of
the union type and put a 32-bit integer into the Lisp_Object
union. Lisp_Objects will necessarily be 64-bit objects at this
point. The same can be done to get 32-bit characters, and we
can have 32-bit integers and 32-bit characters in the same
XEmacs. However, half of each Lisp_Object will be wasted.