Re: Address range returned by malloc
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 4, 2008, at 4:16 PM, Terry Lambert wrote: - Greg _______________________________________________ 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... The short answer is that if you do pointer math on an address above 2G in a signed it, it will subtract rather than add, and you will get the wrong address. Don't do that. The longer answer is that, as an architectural detail, Intel processors expect high bits not current supported to be set instead of cleared, so the compiler sign extends pointers on conversion from integsr before assignment. In both cases, you are getting luck because of the simplicity of your example. No pointer math is occurring in my code, I'm just converting it from unsigned to signed and back, so I'm hoping, as Jeff Stearns pointed out, that this shouldn't ever be a problem on a 32-bit kernel (right?). However, thanks for the warning on the pointer math, that sounds like something I should generally be aware of. In any event, it doesn't matter if I say this because there are over 15,000 google hits on the information: google the terms: SnowLeopard kernel 64bit. You will be very unhappy if you use a 32 bit integer type to contain a kernel pointer in SnowLeopard. Oh dear, now that you mention it I do vaguely remember something about that... I should keep up with the times shouldn't I? Thanks for pointing that out! :-p This email sent to site_archiver@lists.apple.com
participants (1)
-
Greg