我正在尝试编译一些看起来像这样的代码:(示例从第 38 行开始,throw 是 45)
VSShader::VSShader(_In_ ICore * const pCore, _In_ const String & path, _In_opt_ const char ** ppArgs) :
m_Core(pCore), m_Name(path), m_DefaultTechnique(nullptr)
{
CGcontext context = m_Core->GetCgContext();
if (!context || !cgIsContext(context))
{
throw Exception(L"Voodoo/Core", L"Unable to create parameter (core has no context).", pCore, "VSShader.cpp", __FUNCTION__ , 45);
}
int32_t len = m_Name.ToCharStr(0, nullptr);
std::vector<char> buffer(len);
path.ToCharStr(len, &buffer[0]);
m_CgEffect = cgCreateEffectFromFile(context, &buffer[0], ppArgs);
if (!cgIsEffect(m_CgEffect))
{
throw Exception(L"Voodoo/Core", L"Failed to create shader.", m_Core, "VSShader.cpp", __FUNCTION__ , 56);
}
else
{
cgSetEffectName(m_CgEffect, &buffer[0]);
}
this->Link();
}
被调用的 ctor 看起来像:
Exception
(
_In_ wchar_t * Module,
_In_ wchar_t * Message,
_In_opt_ ICore * pCore,
_In_ char * File,
_In_ char * Function,
_In_ int Line
);
当我对此进行分析时,我得到了错误:
1>d:\code\voodooshader\framework\core\vsshader.cpp(45): warning C6385: Invalid data: access 'argument 3', 可读大小为 '1*0' bytes, 但 '4' bytes 可能阅读:行:40、39、41、43
据我所知,这是声称指针有 0 个可读字节,并且我在传递它时尝试使用其中的 4 个(分别不正确和正确)。这是一个 32 位的构建,所以指针应该是 4 个字节。
如果我m_Core
将 throw 中的 更改为,我不会在任何地方nullptr
收到错误,而不仅仅是在 throw 线上(第 39-41 和 43 行也突然缺少错误)。
更不寻常的是,如果我完全注释掉 throw,我会收到:
1>d:\code\voodooshader\framework\core\vsshader.cpp(56): warning C6385: Invalid data: access 'argument 3', 可读大小为 '1*0' bytes, 但 '4' bytes 可能阅读:行:40、39、41、43、48、49、50、52、54
这在看似不相关的行上给出了相同的错误。
该错误的 MSDN 示例似乎与任何有意义的方式无关,讨论了错误的数组访问。
这是某种已知错误、错误还是我只是误读了它?
More importantly, how can I fix it (this is the only warning from the compiler or PREfast, on /w4 /wX, in an 11kloc codebase, because it loves to heap on the hateful irony :P).
Edit: After some discussion and testing, I've discovered two additional oddities:
If I remove the annotations entirely from the _In_ ICore* const pCore
parameter, there is no error.
If I change the annotation on that parameter to _Pre_notnull_ ICore * const pCore
, there is also no error. _Pre_notnull_
has most of the requirements of _In_
, so this is a functional solution for the time being, but does not seem correct.