site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Kernel virtual address space for a 32 bit kernel is limited to 32 bits. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Oct 4, 2008, at 12:10 PM, Greg <greg@kinostudios.com> wrote: When you call OSMalloc, IOMalloc, kern_os_malloc, or any of the other mallocs in the kernel, I'm fairly sure I've read that they all eventually call the same low-level malloc function in the kernel (vm_page_alloc() I believe). My question is what range is this address usually in? Is it reasonable to assume, given the amount of memory used by the kernel in RAM, that it will be less than the maximum value of a signed 32- bit integer, even on 64-bit systems? Or is this not a safe assumption at all? Pointers are NOT signed values, so do not store the returned pointer into a signed integer, or you may truncate it to 31 bits and overwrite/ access something in lower memory than your allocation actually occurred when you go to use it. This would be Bad(tm). If you need a generic pointer type, do not use an integer, use void *. If you absolutely must use an integer type to do math (for example, for a byte count rather than an element count in pointer math), then the appropriate type is intptr_t (which is unsigned). If this value is intended to be communicated to user space, consider using a sized type capable of storing either a 32 or 64 bit pointer, such as user_addr_t or uint64_t. This is normally discouraged, since the likely reason for wanting to do it is because you intend to pass the pointer back into the kernel later, and that would ne a gaping security hole. This email sent to site_archiver@lists.apple.com