什么阻止我阅读/写入比共享内存的大小更远？ （System V IPC）
我在做的是：
shmget(shm_key, shm_size, 0666 | IPC_CREAT); （当然还附上）
我已经将大小设置为12字节但是当我尝试类似的东西时：
sprintf(shm_ptr, "Imagine about 200-300 characters here\n");
它似乎正常工作没有问题或警告，并检查，我试图从一个完全不同的过程（我分叉和执行第一个）读取它，当然
printf("%s", shm_ptr);
打印该段中的消息，该消息应为12字节。 System V IPC是否应该是这样的，并且该问题没有解决方法？ 如果是这样，为什么要设置一个尺寸？
感谢您提前的时间和答案。
没有什么能阻止你，但规范并不保证这种情况的任何特定行为。
实际上，内存区域的实际大小将向上舍入到系统特定的页面大小。 这使得可以访问比请求更多的内存，但可能会有后果。 例如，内存清理程序可能会将此视为错误。
这适用于所有内存映射，包括使用mmap创建的内存映射。
现在，为什么需要访问超出请求区域的内存？ 如果您需要更多内存，只需要更多内存。 内存消毒剂不会因意外行为而变得疯狂，这是非常有用的。 除此之外，我认为没有任何后果，至少我不能提出任何问题。
编辑：如果要在代码中查找访问错误，可以在内存块的末尾放置一个“保护页”。 只需分配一个额外的内存页并使用mprotect更改其对PROT_NONE访问权限。 这样，如果超出映射范围（但不超过1页），您将获得段错误。
没有什么能阻止你尝试使用该地区以外的地址。 但是没有什么可以保护你免受可能的后果
它可能表现得好像该区域更大。 它可能是段错误（或者您平台上的等价物）。 它可能会覆盖随机堆内存，从而导致程序以不可预测的方式行为exception。 它可能会做任何事情 。
C不提供保证你遵守规则的监护人。 守护者是昂贵的，如果你想要一个，你将不得不自己付钱（通过写保护代码，并在必要时执行）。
MMU硬件正在修复页面大小，因此您的虚拟地址空间以4K字节为单位进行组织。
任何虚拟地址段（即使是来自SysV IPCMEM的虚拟地址段）也是该页面大小的倍数。 使用带有PAGESIZE或getpagesize（2）的 sysconf（3 ）来获取它。
（Linux也有“巨大的页面”，例如x86上的1Mbytes）。
顺便说一下，读取proc（5）并考虑使用/proc/self/maps或/proc/1234/maps进行pid 1234的过程来查询该进程的虚拟地址空间 ….
PS。 更喜欢使用shm_overview（7） 。