Hey, You were right and wrong. Using min() wouldn't help since we pass the overflowed result of the addition, which could be say 1, even when there is _much_ more memory available on the computer. It could happen on 64-bit systems too when the user has a lot of memory (say 64 GiB, we don't see these today a lot, if at all).
I've prepared a new version of the patch, hopefully it is good enough. It seems that on Mac and Unix systems, the function mch_avail_mem() isn't used or even defined at all, so this patch is only needed for Windows at the time. -- Jelle Geerts On Sun, Aug 24, 2008 at 5:00 AM, George V. Reilly <[EMAIL PROTECTED]> wrote: > > 2008/8/23 Jelle Geerts <[EMAIL PROTECTED]>: >> Hello, >> >> When allocating memory, lalloc() is called, which uses mch_avail_mem(). But >> mch_avail_mem() sometimes fails. It returns the available physical memory + >> available page file memory, which can sometimes wrap around 32-bits. >> >> Also, mch_avail_mem() uses GlobalMemoryStatus() which isn't working properly >> on >> computers with more than 4 GiB of memory installed. There is an extension >> available on NT platforms 0x0500, called GlobalMemoryStatusEx(). As opposed >> to >> GlobalMemoryStatus(), the extension works reliably with systems that have >> more >> than 4 GiB of memory installed. >> >> Please see the attachment for the diff file for my patch. If the comments I >> have added are too wordy or someone does not like them, just remove them ;) >> >> Thanks, >> Jelle Geerts > > It looks to me like your patch will fail if ms.dwAvailPhys is more > than 4GiB, due to underflow of (0xffffff00 - ms.dwAvailPhys). This is > a DWORDLONG, which is always an unsigned 64-bit int. > > Also, shouldn't that be msex.ullAvailPhys, not ms.dwAvailPhys in the > (_WIN32_WINNT >= 0x0500) && !defined(_WIN64) case? > > Better, I think, to return (long_u) min(0xFFFFFF00, msex.ullAvailPhys > + msex.ullAvailPageFile). Or for Bram to widen this signature to a > 64-bit int for all platforms. Linux and Mac boxes with >4GiB are going > to be common soon. > -- > /George V. Reilly [EMAIL PROTECTED] > http://www.georgevreilly.com/blog http://blogs.cozi.com/tech > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
