/GZ编译选项加上之后出现问题，肯定是release版本出错，那么一般出错的情形是什么？我找了好久也没有找出来，大家给点提示？

[zl_2001]

反复试了几次都是/GZ作怪，查msdn好像没有确定的答案！

[han012]

从我的经验看,Debug(也可能是Release)版本程序中由于/GZ的作用,在每个函数的"prolog/epilog sequences"(由编译器自动加入的代码)中,包含如下功能:

自动初始化局部变量. Auto-initialization of local variables
堆栈检查. Function pointer call stack validation

而在生成另一个版本时(Debug也可能是Release?)没有/GZ选项,所以对局部变量不进行自动初始化.

所以如果你的程序中,忘了对局部变量进行初始化,则一个版本可能可以运行,而另一个版本则死机. 另外,即使自动初始化也可能不是你要的结果. 所以事先对所有局部变量进行初始化才是解决你的问题的关键所在.
/GZ只是提供一个方法让你在一个版本中发现另一个版本中可能的问题!

具体信息请参见MSDN中关于/GZ的解释.

/GZ (Catch Release-Build Errors in Debug Build)

Some bugs normally arise only when you switch to a Release build (/O1, /O2, /Ox, or /Og). You can use the /GZ option to enable run-time checks to catch these bugs in a Debug (/Od) build. /GZ is not compatible with /O1, /O2, /Ox, or /Og builds.

Note: Use of the /GZ option will disable any #pragma optimize statements in your code.

The /GZ option does the following:

Auto-initialization of local variables


Function pointer call stack validation


Call stack validation
See Creating a Release Build: Overview for more information on going from Debug builds to Release builds.

Auto-initialization of Local Variables
/GZ initializes all local variables not explicitly initialized by the program. It fills all memory used by these variables with 0xCC.

Assuming the stack is zero, code with uninitialized variables may fail with /GZ. Consider the following example. When compiled with /Od or /Ox without /GZ, this code may produce an access-violation exception, or it may appear to run correctly. When compiled with /Gz /Od, it always produces the exception. You can catch the exception in the debugger and get some hints about the exact location of failure.

#include <stdio.h>

void function1(char **pptr)
{
printf("*pptr = 0x%X\n", *pptr);
if(*pptr == NULL)
*pptr = "Hello world\n";
}
void function2()
{
int padding[10]; // force sub esp frame initialization
char * p; // p is uninitialized

function1(&p);
puts(p);
}

void main()
{
int padding[1000]; // Force clean stack page
function2();
}

Function Pointer Call Stack Validation
The stack pointer (ESP) is checked to make sure it is the same before and after the call through the function pointer. This can catch any mismatch between the calling function’s cleanup (__cdecl) calling convention and called function’s cleanup calling conventions (__sdtcall, __fastcall, __thiscall) when calling through a function pointer.

This example works with /Od, fails with /Ox and raises an exception with /GZ. You get an exception breakpoint pop-up if compiled with a release version of the run-time library and a more meaningful message when compiled with the debug version of the run-time library.

void __stdcall function1(char *p)
{
puts(p);
}

typedef void (*PFUNC)(char *);

main()
{
PFUNC pfunction1 = (PFUNC)function1;

pfunction1("Hello world\n");
}

A more realistic scenario occurs with GetProcAddress:

#include <windows.h>
void function1()
{
typedef int (*FPTYPE)(int); // should be "int(__stdcall *)(int)"
FPTYPE fp;
int ret = 0;
HINSTANCE hinst = LoadLibrary( "your.dll" );
fp = (FPTYPE) GetProcAddress( hinst, "SomeFunc");

ret = (*fp)(22); // ESP invalid after this call.
// but it is caught upon return

FreeLibrary( hinst );

// and also caught at function exit
}

Function pointer call stack validation will also catch cases where a function prototype has the incorrect number of parameters if the function uses the __stdcall, __fastcall, or __thiscall calling convention. __cdecl cases are not caught because the caller does both the pushes and the pops of parameters.

Call Stack Validation
The stack pointer (ESP) is checked at the end of the function to see that the stack pointer has not been changed. This can catch cases where ESP is corrupted in inline assembly or a non-pointer function's calling convention is declared incorrectly.

[zl_2001]

这个问题我也看到了，但是与project调用的dll版本有何关系？project是否能够调用dll的任何版本（debug或release）?
请参考问题2：
http://www.csdn.net/expert/topic/538/538111.xml
谢谢！

[zl_2001]

在debug版本不加/GZ开关会不会有问题？隐含错误？