GNU bug report logs - #8794
cons_to_long fixes; making 64-bit EMACS_INT the default

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8794 <at> debbugs.gnu.org
Subject: bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default
Date: Fri, 03 Jun 2011 10:53:55 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.