0109:0000<\/code>. <\/p>\nBut why do you add 8 to move to the next selector? Why not just increment the selector? Because the bottom three bits of the selector are used for other things. In particular, the bottom bit of the selector is used to choose the selector table. Let’s ignore bits 1 and 2 since they are not relevant to the discussion. Assume for convenience that they are always zero.² <\/p>\n
There are two tables which describe how selectors correspond to physical memory, the Global Descriptor Table (for memory shared across all processes) and the Local Descriptor Table (for memory private to a single process). Therefore, the selectors available for process private memory are 0001<\/code>, 0009<\/code>, 0011<\/code>, 0019<\/code>, etc<\/i>. Meanwhile, the selectors available for global memory are 0008<\/code>, 0010<\/code>, 0018<\/code>, 0020<\/code>, etc<\/i>. (Selector 0000<\/code> is reserved.) <\/p>\nOkay, now we can set up our counter-example. Suppose regionStart = 0101:0000<\/code> and regionSize = 0x00020000<\/code>. This means that the guarded addresses are 0101:0000<\/code> through 0101:FFFF<\/code> and 0109:0000<\/code> through 0109:FFFF<\/code>. Furthermore, regionStart + regionSize = 0111:0000<\/code>. <\/p>\nMeanwhile, suppose there is some global memory that happens to be allocated at 0108:0000<\/code>. This is a global memory allocation because the selector is an even number. <\/p>\nObserve that the global memory allocation is not part of the guarded region, but its pointer value does satisfy the numeric inequality 0101:0000<\/code> ≤ 0108:0000<\/code> < 0111:0000<\/code>. <\/p>\nBonus chatter<\/b>: Even on CPU architectures with a flat memory model, the test can fail. Modern compilers take advantage of undefined behavior and optimize accordingly. If they see a relational comparison between pointers, they are permitted to assume that the pointers point into the same aggregate or array (or one past the last element of that array), because any other type of relational comparison is undefined. Specifically, if regionStart<\/code> points to the start of an array or aggregate, then the only pointers that can legally be relationally compared with regionStart<\/code> are the ones of the form regionStart<\/code>, regionStart + 1<\/code>, regionStart + 2<\/code>, …, regionStart + regionSize<\/code>. For all of these pointers, the condition p >= regionStart<\/code> is true and can therefore be optimized out, reducing the test to <\/p>\n\nif (p < regionStart + regionSize)\n<\/pre>\nwhich will now be satisfied for pointers that are numerically less than regionStart<\/code>. <\/p>\n(You might run into this scenario if, as in the original question that inspired this answer, you allocated the region with regionStart = malloc(n)<\/code>, or if your region is a “quick access” pool of preallocated items and you want to decide whether you need to free<\/code> the pointer.) <\/p>\nMoral of the story<\/b>: This code is not safe, not even on flat architectures. <\/p>\n
But all is not lost<\/b>: The pointer-to-integer conversion is implementation-defined, which means that your implementation must document how it works. If your implementation defines the pointer-to-integer conversion as producing the numeric value of the linear address of the object referenced by the pointer, and you know that you are on a flat architecture, then what you can do is compare integers<\/i> rather than pointers<\/i>. Integer comparisons are not constrained in the same way that pointer comparisons are. <\/p>\n\n if ((uintptr_t)p >= (uintptr_t)regionStart &&\n (uintptr_t)p < (uintptr_t)regionStart + (uintptr_t)regionSize)\n<\/pre>\n¹ Note that comparison for equality and inequality are not considered relational comparisons. <\/p>\n
² I know that in practice they aren’t. I’m assuming they are zero for convenience. <\/p>\n
(This article was adapted from my answer on StackOverflow<\/a>.) <\/p>\nUpdate<\/b>: Clarification that the “start of region” optimization is available only when regionStart<\/code> points to the start of an array or aggregate. <\/p>\n","protected":false},"excerpt":{"rendered":"Thanks to the C language standard, it’s trickier than it seems.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-97095","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Thanks to the C language standard, it’s trickier than it seems.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/97095","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=97095"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/97095\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=97095"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=97095"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=97095"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}