问题
What I'm doing is:
shmget(shm_key, shm_size, 0666 | IPC_CREAT); (and of course attach to it)
and I've already set the size to exactly 12 Bytes but when i try something like:
sprintf(shm_ptr, "Imagine about 200-300 characters here\n");
it seems to work normally with zero problems or warnings, and to check that, I tried to read it from a completely different process (i fork and exec the first one) and sure enough
printf("%s", shm_ptr);
prints the message that was in that segment, which is supposed to be 12 Bytes. Is System V IPC supposed to be like this, and there is no workaround for that issue? If so, why set a size in the first place?
Thanks for your time and answers in advance.
回答1:
Nothing stops you, but the spec does not guarantee any specific behavior for this case.
In practice, the actual size of a memory region will be round up to a system-specific page size. This makes it possible to access more memory than was requested, but there might be consequences. For example, memory sanitizers might treat this as an error.
This is true for all memory mapping, including those created with mmap.
Now, why do you need to access memory beyond requested region? If you need more memory, just request more. Having memory sanitizers not going crazy due to unexpected behavior is a very useful thing. Other than that, I don't think there are any consequences to this, at least I cannot come up with anything atm.
EDIT:
If you want to find access errors in your code, you can put a single "guard page" at the end of your memory block. Just allocate one additional page of memory and use mprotect to change its access rights to PROT_NONE. This way you will get segfault if you go beyond your mapping (but no more than 1 page).
回答2:
Nothing stops you from trying to use addresses outside of the region. But nothing protects you from possible consequences either.
It might just behave as though the region was larger. It might segfault (or whatever the equivalent is on your platform). It might overwrite random heap memory, causing your program to misbehave in unpredictable ways. It might do anything.
C does not provide a guardian who guarantees you are playing by the rules. Guardians are expensive and if you want one, you will have to pay for it yourself (by writing the guard code, and executing it as and when necessary).
回答3:
The MMU hardware is fixing the page size, so your virtual address space is organized in pages of 4Kbytes.
Any virtual address segment (even the one from SysV IPCMEM) is a multiple of that page size. Use sysconf(3) with PAGESIZE or getpagesize(2) to get it.
(and Linux has also "huge pages" e.g. of 1Mbytes on x86).
BTW, read proc(5) and consider using /proc/self/maps or /proc/1234/maps for the process of pid 1234 to query the virtual address space of that process ....
PS. Prefer using shm_overview(7).
来源：https://stackoverflow.com/questions/47479323/what-stops-me-from-reading-writing-further-than-the-size-of-a-shared-memory-sy