Scanf traps in C

From http://westsoftware.blog.163.com/blog/static/2609410920091953456841/

I have been reading books written by Andrew Koening recently. It can be said that C/C ++ or people engaged in such development are worth reading, here I recommend you read "C traps and defects" and "C/C ++ meditation".

Let's take a look at the code section "C traps and defects.

# Include <stdio. h>
Int main ()
{
Int I;
Char C;
// Printf ("I address: % LD/N", & I );
// Printf ("c Address: % LD/N", & C );
For (I = 0; I <5; I ++)
{
Scanf ("% d", & C );
Printf ("% d", I );
}
Return 0;
}

============

With such a small piece of code, you can see what the running result will be? C is a character variable.

At the beginning, I didn't quite understand what he was talking about. To make it clearer, I analyzed the memory structure.

Because scanf points to an integer pointer, C receives character input at this time. Therefore, some memory addresses of I are overwritten when inputting data to C, how to cover it? In fc6, I will overwrite the low-end address of I to the high-end address of C. I don't know if I can understand it? That is to say, C actually receives an integer variable, but C cannot store it. What should I do if there is more? It overwrites the high-end address bit of C into the low-end address bit of I, so the I value is always 0, so running this program is an endless loop.

Comment out the two sections above to print the addresses of C and I. The printed Address here is continuous.

But in vc6, it can run normally. That is, the memory address overwrite method I mentioned is different. In other words, how to overwrite is determined by the compiler? I guess so here, when the VC overwrites the memory, it is the left-side memory of c instead of the memory address of I. Therefore, it can be normal in VC.

This is also a conjecture. In FC, "to the right" is used for overwriting.

Therefore, during development, you must note that once this trap is entered, it will be difficult to debug, and sometimes there is a kind of "coincidentally" to avoid this problem, making it even harder to check errors. I hope you can have some reference for future development.