[Top][All Lists]

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

bug#8884: closed (Re: bug#8884: wide-int crash)

From: Stefan Monnier
Subject: bug#8884: closed (Re: bug#8884: wide-int crash)
Date: Tue, 18 Oct 2011 09:33:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

>> 4 GiB is 16 times that value, quite a bit more. Maths with large
>> numbers, greater than 2**28, works.
> Exactly.  So with this option, you can:
>   . visit files or have buffers up to 4GB

Actually, it will usually be less than 4GB, it depends on the amount of
space the OS gives us (it can be as little as 2GB).  E.g. you definitely
won't be able to open two files of 2.5GB each.

The current buffers.texi is fairly clear:

     A buffer's size cannot be larger than some maximum, which is defined
   by the largest buffer position representable by the @dfn{Emacs
   integer} data type.  This is because Emacs tracks buffer positions
   using that data type.  For typical 64-bit machines, the maximum buffer size
   enforced by the data types is @math{2^61 - 2} bytes, or about 2 EiB.
   For typical 32-bit machines, the maximum is @math{2^29 - 2} bytes, or
   about 512 MiB.  Buffer sizes are also limited by the size of Emacs's
   virtual memory.

So w.r.t accessing large files, --with-wide-int pushes the limit from
512MB to "a bit less than 4GB".  That's one of the reasons why I'm not
convinced it's worth the trouble, tho admittedly, the zone between 512MB
and 4GB might contain a fair number of mbox files, so it can be useful
for Rmail users.

> None of these is possible without this option.  The first of these two
> advantages is the more important one: Emacs can now access the largest
> files supported by the OS, instead of having a more-or-less arbitrary
> limit below that.

Of course, it's actually not "the largest files supported by the OS",
since most OSes nowadays happily handle files larger than 4GB, even on
32bit systems.


reply via email to

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