site_archiver(a)lists.apple.com
Delivered-To: darwin-kernel(a)lists.apple.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.…
This email sent to site_archiver(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: darwin-kernel(a)lists.apple.com
On May 31, 2005, at 1:28 PM, Tony Scaminaci wrote:
What's the "horrendously huge" number?
FreeMem = ((unsigned long long) vm_stat.free_count) * mac_pagesize;
should work just fine on all architectures.
William Kucharski
kucharsk(a)mac.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.…
The following calculation of free memory (in bytes) works correctly
on 32-bit platforms. On 64-bit systems (Tiger + G5),
the result is a horrendously huge number rather than what is
expected. I'm sure this is one of the conversion issues covered
in the 64-bit transition guide (which I've read over multiple times
already) but I can't seem to nail down the right
way to do this calculation for both 32 and 64-bit systems.
vm_size_t mac_pagesize;
unsigned long long FreeMem; // Free real (physical)
memory in bytes
The correct way to do this is to cast the number of pages to an
unsigned long long and multiply it by mac_pagesize, so the initial
code sample you had:
This email sent to site_archiver(a)lists.apple.com