[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default
From: |
Paul Eggert |
Subject: |
bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default |
Date: |
Fri, 03 Jun 2011 10:53:55 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 |
>> I wrote some code to fix them systematically, and found that
>> it was simpler and more reliable if I could assume that EMACS_INT
>> was 64-bit even on 32-bit hosts.
>
> I don't think we agreed to make that the only configurations on 32-bit
> machines.
Sorry, I should have explained more clearly. If there is a system
integer type (such as ino_t or time_t) that is 64 bits, it's cleaner
if EMACS_INT is also 64 bits. And in practice this requirement is not
a problem, as any 32-bit host where some standard system types are 64 bits
supports 64-bit integers quite well. On an old-fashioned host where
all the system types are 32 bits, EMACS_INT can still be 32 bits.
> Can 32-bit hosts really support buffers and strings larger than 2GB,
> even if EMACS_INT is a 64-bit type?
Yes, absolutely. For example:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int
main (void)
{
int big = 536870913;
int *p = malloc (big * sizeof *p);
if (!p)
return 1;
memset (p, 0xef, big * sizeof *p);
printf ("%x %x\n", p[0], p[big - 1]);
return 0;
}
On my RHEL 5.6 host, built as a 32-bit executable, this outputs:
$ gcc -m32 t.c
$ ./a.out
efefefef efefefef
even though the array's size does not fit in 'int' or 'long'.
The same behavior can be observed on pure 32-bit systems;
it's quite common and has been for years.
> I thought the largest object on a
> 32-but machine cannot exceed 2GB due to pointer arithmetics,
No, but as shown above one can often allocate objects larger than 2 GiB
on such machines.
Perhaps you're thinking of pointer subtraction? That often stops working on
arrays larger than 2 GiB. But this is easy to program around. And
anyway, even if we assume buffers and strings are all smaller than 2
GiB, an EMACS_INT wider than 32 bits is still needed for large buffers
and strings, due to the tag bits.
>> Emacs cannot visit files that are larger than the maximum Emacs buffer
>> -size, which is around 512 megabytes on 32-bit machines
>> +size, which is around 512 MiB on 32-bit machines and 2 EiB on 64-bit
>> machines
>> (@pxref{Buffers}). If you try, Emacs will display an error message
>> saying that the maximum buffer size has been exceeded.
>
> This seems to contradict what you said about buffers, doesn't it?
Yes, thanks, I messed that up; I'll fix that part of the documentation.
>> + if (NATNUMP (top) && XFASTINT (top) <= UINTMAX_MAX >> 16 && NATNUMP
>> (bo>
> The *_MAX macros need limits.h, but I don't see it being included by
> data.c. Did I miss something?
Those are OK because lisp.h includes inttypes.h. INTMAX_MAX and
UINTMAX_MAX are defined by inttypes.h (actually, stdint.h, but
inttypes.h includes stdint.h). Like you, I would have put all the
_MIN and _MAX macros into limits.h, but I wasn't part of that
design decision.