The program I\'m working on crashes sometimes trying to read data at the address 0xCCCCCCCC
. Google (and StackOverflow) being my friends I saw that it\'s the MS
How about this? Ignore the warning that VC throws while running.
struct A{
int *p;
};
int main(){
A a;
cout << (void *)a.p;
}
int main()
{
int* p;
}
If you build with the Visual C++ debug runtime, put a breakpoint in main()
, and run, you will see that p
has a value of 0xcccccccc
.
I do not have MSVC, but this code should produce the problem and compile with no warnings.
In file f1.c:
void ignore(int **p) { }
In file f2.c:
void ignore(int **p);
int main(int c, char **v)
{
int *a;
ignore(&a);
return *a;
}
The call to ignore
makes it look like a
might be initialized. I doubt the compiler will warn in this case, because of the risk that the warning might be a false positive.
Compile your code with the /GZ compiler switch or /RTCs switch. Make sure that /Od switch is also used to disable any optimizations.
s
Enables stack frame run-time error checking, as follows:
Initialization of local variables to a nonzero value. This helps identify bugs that do not appear when running in debug mode. There is a greater chance that stack variables will still be zero in a debug build compared to a release build because of compiler optimizations of stack variables in a release build. Once a program has used an area of its stack, it is never reset to 0 by the compiler. Therefore, subsequent, uninitialized stack variables that happen to use the same stack area can return values left over from the prior use of this stack memory.
Detection of overruns and underruns of local variables such as arrays. /RTCs will not detect overruns when accessing memory that results from compiler padding within a structure. Padding could occur by using align (C++), /Zp (Struct Member Alignment), or pack, or if you order structure elements in such a way as to require the compiler to add padding.
Stack pointer verification, which detects stack pointer corruption. Stack pointer corruption can be caused by a calling convention mismatch. For example, using a function pointer, you call a function in a DLL that is exported as __stdcall but you declare the pointer to the function as __cdecl.