-1

Why is it that I can increment pointers to read past the length of an allocated variable, and the OS doesn't stop me? Surely, since it was the one that set aside 4 bytes for an integer, it should know that it shouldn't allow any pointer to go past those 4 bytes?

In fact, when I increment a pointer past the allocated bytes of a variable, what exactly am I reading/ Are those adjacent memory locations? And since each program is supposed to have its own "address space", can't I do anything I want within that "address space" without a segfault? It should be impossible to read memory that belongs to other programs if each program had its own "address space", right?

randomshinichi
  • 420
  • 5
  • 15
  • Use a memory managed framework like .NET or Java then. C isn't built for this. – Patrick Hofman May 08 '14 at 21:52
  • 4
    This is not a great question for SO and will likely be closed. But fortunately for you I answered your question on my blog yesterday. http://ericlippert.com/2014/05/07/why-does-my-code-not-crash/ – Eric Lippert May 08 '14 at 21:52
  • 1
    Your error, incidentally, is in the statement "surely since it was the one that set aside four bytes"... It *wasn't* the operating system that set aside four bytes. The OS set aside *four thousand bytes* and *malloc* decided to use four of those for an integer. I have often noticed that the word "surely" indicates where the error is. – Eric Lippert May 08 '14 at 21:54
  • See also this question about a related situation: accessing memory that is no longer valid: http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope/6445794#6445794 – Eric Lippert May 08 '14 at 21:54

2 Answers2

3

I note that this question was the subject of my blog yesterday. See http://ericlippert.com/2014/05/07/why-does-my-code-not-crash

Why is it that I can increment pointers to read past the length of an allocated variable, and the OS doesn't stop me?

For the same reason that the OS doesn't make you a ham sandwich! No one wrote a ham sandwich feature into the operating system, and so the behaviour does not occur. Features that are not implemented are not implemented. Stopping you from doing that is not a feature of the operating system you're using.

Surely, since it was the one that set aside 4 bytes for an integer, it should know that it shouldn't allow any pointer to go past those 4 bytes?

Nope. The operating system sets aside address space in 4KB chunks called pages, typically.

In fact, when I increment a pointer past the allocated bytes of a variable, what exactly am I reading? Are those adjacent memory locations?

Yes. They are adjacent virtual memory locations.

since each program is supposed to have its own "address space", can't I do anything I want within that "address space" without a segfault?

No. You can do anything in the address space to an address that has been virtually allocated. Note that many operating systems allow you to put additional constraints on pages, such as "this page may be read from but not written to or executed". In those cases reads will not cause faults but writes will.

It should be impossible to read memory that belongs to other programs if each program had its own "address space", right?

It is not impossible but it typically is deliberate. In many operating systems two processes can both map the same page of a file on disk into virtual memory simultaneously, and thereby share memory.

Back in the pre-virtual-memory days operating systems like Windows 3 would allow two processes to write to each other's memory no problem, but that hasn't been the case for decades now.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
0

The compiler could do this, but it chooses not to because the runtime overhead imposes a severe performance penalty if you are doing it for every single memory access.

Some compilers come with an option to enable this check that you can use while debugging.

Eric Lippert's comment answers your second paragraph.

M.M
  • 138,810
  • 21
  • 208
  • 365