blocks|key|2611325|text|由于ASLR等因素，以及C规范中关于变量在内存中的实际位置的特殊性，您确实不能相信两个指向两个不同对象的指针之间的差异来表示任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2611326|堆栈上的东西是否以自顶向下的方式分配？当然，通常情况下，这是一个由来已久的惯例，但并不要求是这样的。它们可以是堆分配的，也可以是随机分布的。这不太可能，但允许。|2611327|在任何保护模式的操作系统中，您都看不到真正的内存地址，它们是用户空间地址，它们看起来和感觉都非常真实，但是CPU将它们重新映射到内存中的实际位置，或者甚至没有，因为该内存可能被交换到磁盘、压缩或其他由内核和CPU隐藏的更神秘和更令人困惑的东西上。|2611328|虽然可以通过malloc或calloc获取给定分配中两个位置的差异，但两个任意分配或对象之间的差异实际上是没有意义的。内核不仅添加了一个抽象层，而且它还会故意搅乱它通过地址空间布局随机化给您的分配，作为一种措施，使您的分配更加不可预测。|offset|length|style|CODE|2611329|为什么？使缓冲区溢出错误更难武器化。|2611330|因此，如果您对内存中变量的位置感到好奇，那很好，请看一看，探索一下，但不要假设编译器、操作系统或CPU所使用的策略在将来不会发生戏剧性的变化。|2611331|在任何现代64位CPU和操作系统上，都有大量的地址空间可供使用，比如18,446,744,073,709,551,616个可能的字节，虽然其中的大部分被隔离和保留，但仍然有一个几乎用之不竭的空间。这也乘以每个进程都有自己的地址空间，所以实际上比理论上要处理的要多得多。|2611332|有趣的事实:在64位CPU开始应用之前，有一些不寻常的36位内存方案，32位操作系统和CPU可以处理超过4GB的内存，但是每个单独的进程只能“看到”4GB，因为它使用32位指针。|2611333|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Address_space_layout_randomization|1|https://en.wikipedia.org/wiki/Buffer_overflow^0|0|0|0|6|6|D|6|2C|9|0|0|5|7|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|16|8|@$H|17|I|18|J|K]|$H|19|I|1A|J|K]]|9|@$H|1B|I|1C|1|1D]]|A|$]]|$1|L|3|M|5|6|7|1E|8|@]|9|@$H|1F|I|1G|1|1H]]|A|$]]|$1|N|3|O|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1J|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1K|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]|11|$5|W|X|Y|A|$Z|12]]]]

Due to factors like ASLR, and the lack of specificity in the C specification regarding how variables are actually positioned in memory, you really can't trust the difference of two pointers to two different objects to represent anything.
Are things allocated on the stack in a top-down manner? Usually, sure, it's a long-standing convention, but it is not required to be that way. They could be heap allocated, or strewn about randomly. That's unlikely, but allowed.
In any protected mode operating system you are not seeing real memory addresses, they're user-space addresses that might look and feel very real, but they're remapped by the CPU to their actual location in memory, or perhaps not even, as that memory could have been swapped out to disk, compressed, or other more mysterious and confusing things that are all hidden away by the kernel and CPU.
While you can take the difference of two locations within a given allocation, as in through <code>malloc</code> or <code>calloc</code>, the difference between two arbitrary allocations or objects is really not meaningful. Not only does the kernel add an abstraction layer, it will deliberately scramble the allocations it gives you through <a href="https://en.wikipedia.org/wiki/Address_space_layout_randomization" rel="nofollow noreferrer">Address Space Layout Randomization</a> as a measure to make your allocations more unpredictable.
Why? To make it harder to weaponize a <a href="https://en.wikipedia.org/wiki/Buffer_overflow" rel="nofollow noreferrer">buffer overflow bug</a>.
So if you're curious about the position of variables in memory, that's great, have a look, explore, but don't presume that the strategy used by your compiler, operating system, or CPU won't change in the future in some dramatic way.
On any modern 64-bit CPU and operating system there's a huge amount of address space to work with, like 18,446,744,073,709,551,616 possible bytes, and while large chunks of this are walled off and reserved, there's still a nearly inexhaustible amount of space left. That's also multiplied by the fact that each process has its own address space, so there's actually a lot more than that in theory to work with.
Fun fact: Before 64-bit CPUs took hold there were unusual 36-bit memory schemes where a 32-bit operating system and CPU could address more than 4GB of memory, but each individual process could only &quot;see&quot; 4GB since it uses 32-bit pointers.

blocks|key|2611376|text|指针算法仅在指针具有相同类型且指向同一对象时才定义。更具体地说，标准说：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2611377|第三条减法应当有下列情形之一：|blockquote|2611378|这两个操作数都有算术类型；|unordered-list-item|2611379|这两个操作数都是指向兼容的完整对象类型的合格或非限定版本的指针；或|2611380|左操作数是指向完整对象类型的指针，右操作数具有整数类型。|2611381|以及：|2611382|9当两个指针被减去时，两个指针都将指向同一个数组对象的元素，或者指向数组对象的最后一个元素；结果是两个数组元素下标的差异。|2611383|(为了解释上面的内容，单个对象被视为一个带有一个元素的数组。)|2611384|将指针类型转换为char+*将在第3条中处理约束，但指向d的指针并不指向i的元素。所以你不能减去它们。|style|CODE|2611385|entityMap|0|LINK|mutability|MUTABLE|url|http://port70.net/%257Ensz/c/c11/n1570.html#6.5.6^0|W|2|0|0|0|0|0|0|0|0|0|8|6|S|1|10|1|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|F|7|19|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1A|8|@]|9|@]|C|$]]|$1|J|3|K|5|I|7|1B|8|@]|9|@]|C|$]]|$1|L|3|M|5|I|7|1C|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1D|8|@]|9|@]|C|$]]|$1|P|3|Q|5|F|7|1E|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|1F|8|@]|9|@]|C|$]]|$1|T|3|U|5|6|7|1G|8|@$A|1H|B|1I|V|W]|$A|1J|B|1K|V|W]|$A|1L|B|1M|V|W]]|9|@]|C|$]]|$1|X|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]]|Y|$Z|$5|10|11|12|C|$13|14]]]]

Pointer arithmetic is only defined when the pointers have the same type and they point within the same object. More specifically, the <a href="http://port70.net/%7Ensz/c/c11/n1570.html#6.5.6" rel="nofollow noreferrer">standard</a> says:
<blockquote>
3 For subtraction, one of the following shall hold:
<ul>
<li>both operands have arithmetic type;</li>
<li>both operands are pointers to qualified or unqualified versions of compatible complete object types; or</li>
<li>the left operand is a pointer to a complete object type and the right operand has integer type.</li>
</ul>
</blockquote>
and:
<blockquote>
9 When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements.
</blockquote>
(For the purposes of interpreting the above, a single object is treated as an array with one element.)
Casting the pointer types to <code>char *</code> addresses the constraint in clause 3, but a pointer to <code>d</code> is not pointing to an element of <code>i</code>. So you can't subtract them.

blocks|key|739705|text|分配给malloc的内存可用于任何具有基本对齐要求的对象，其中包括所有“内置”类型(例如，编译器可能作为扩展提供的特殊类型)，根据C+2018+7.22.3+1，因此所有这些对象都必须共享malloc使用的地址空间。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|739706|此外，任何类型的对象都可以放在结构或联合中，因此必须共享地址空间。|739707|entityMap^0|3|6|2M|6|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Memory allocated for <code>malloc</code> may be used for any object with a fundamental alignment requirement, which includes all the “built in” types (e.g., including special types a compiler might provide as an extension), per C 2018 7.22.3 1, and therefore all such objects must share the address space used by <code>malloc</code>.
Further, any types of objects can be put into a structure or union together and therefore must share an address space.

I am trying to work out if the C standard require that all addresses are in the same address space. If I have two objects of different type
<pre><code>double d;
int i;
</code></pre>
I cannot do pointer arithmetic on their addresses, because they are pointers of different types. However, the standard says that I can point character type pointers there and will get the address of the first byte in the objects.
<pre><code>char *dp = (char *)&amp;d;
char *ip = (char *)&amp;i;
</code></pre>
and with those I can do pointer arithmetic, and for example figure out how far apart they are in memory, <code>(dp - ip)</code>. That is, of course, if doubles and ints sit in the same memory. They always do on the platforms I know, but is it guaranteed by the standard? Or is pointer arithmetic only allowed if my <code>char</code> pointers actually point at something with the same type?

Do all objects sit in the same address space in C?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在试图计算C标准是否要求所有地址都在同一个地址空间中。如果我有两个不同类型的对象double d;int i;我不能对它们的地址执行指针运算，因为它们是不同类型的指针。但是，标准说我可以将字符类型指针指向那里，并获得对象中第一个字节的地址。char *dp = (char *)&d;char *ip = (char...

问所有对象是否都位于C中相同的地址空间？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问所有对象是否都位于C中相同的地址空间？EN