-6

Seems comments/answers just simply stops at C standard description, let's discuss a bit more deep with implementation specific.

I saw below code in other discussion:

struct { size_t x; char a[]; } *p;
p = malloc(sizeof *p + 100);
if (p)
{
    /* You can now access up to p->a[99] safely */
}

Then what if keep accessing p->a[i], 99< i < 0xffff or even bigger value?

  1. malloc implementation should have a virtual memory block backed area for "(sizeof *p + 100)", so after "i" exceeds 100, initially it should be just corrupt data within the virtual memory block which might be non harmful.

  2. if later "i" exceed that virtual memory block size, while next block is available and is never physical memory backed up(means ready to be allocated), would copy-on-write in kernel physical memory happens for next block on this bad access? And would malloc() later aware of this?

  3. if next block is not in heap management, should p->a[i] get a virtual memory access violation error? Because malloc() is not called, so brk/sbrk won't be triggered to expand memory region of process heap.

Just curious how damage it is in this case...

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Brett
  • 9
  • 2
  • 1
    Undefined behavior is undefined. The language will generally let you shoot yourself in the foot like this. Unchecked accesses are faster. – AndyG Jul 30 '17 at 00:44
  • The answer to "what happens if I do [thing I'm not allowed to do]" in either C or C++ is usually that the program is allowed to do literally anything as a result. – user2357112 Jul 30 '17 at 00:48
  • I don't think this should be closed for being unclear. Brett is specifically asking what behavior occurs in that case. – EvilTeach Jul 30 '17 at 00:55
  • >>Undefined behavior is undefined. maybe can think under certain lib implementation? – Brett Jul 30 '17 at 01:00
  • @Brett *Just curious how damage it is in this case...* -- All of this research you're attempting to do can be thrown in the trash if the compiler implementation decides to do something different in a later version, or using different compiler options, etc. So is it worth your time to chase the moving target called "undefined behavior"? – PaulMcKenzie Jul 30 '17 at 01:12
  • @PaulMcKenzie, >>if the compiler implementation decides. You are correct. discuss under certain implementation is exactly what I hoped, maybe I should make more clear. – Brett Jul 30 '17 at 01:44
  • You're going to have to work around the SO community reluctance to discuss UB (which does have a decent reason). Maybe by making this an x86 assembly question - it's still undefined, but maybe less frowned upon. x86 manuals don't go around warning you about stuff, they just assume you have better common sense (which says something about how high level language creators see their users...) – Leeor Jul 30 '17 at 02:04
  • It's a pointless waste of time to discuss UB here. It's a pointless waste of time to discuss some scenario that may be different on different machines. It's a pointless waste of time to discuss some scenario that may different at different times. It's a pointless waste of time to discuss some scenario that may be different on different OS. Ditto compilers. Ditto processors, Ditto MMU hardware. Etc.. etc.. etc.. If the OP wishes to explore what happens in its own environment, fine, but we cannot sensibly help with it. It's a waste of time. It is a time waster. It uses up time wastefully. – Martin James Jul 30 '17 at 08:30
  • 1
    Possible duplicate of [What happens if I try to access memory beyond a malloc()'d region?](https://stackoverflow.com/questions/1655971/what-happens-if-i-try-to-access-memory-beyond-a-mallocd-region) – EvilTeach Jul 30 '17 at 14:20

1 Answers1

6

Accessing stuff outside of the allocated memory is undefined behavior. Anything can happen. I hear nasal demons are a possibility.

nasal demons

If you are really lucky, you might get an access violation/segfault. If you aren't lucky, then some other variable in the program may be overwritten, or nothing observable may happen, The moon may turn into the 7UP logo, or maybe something nasty squeezes out of your right nostril.

EvilTeach
  • 28,120
  • 21
  • 85
  • 141