静态代码分析工具可简化编码过程，检测出错误并帮助修复。有个国外团队检测了 200 多个 C/C++ 开源项目，包括了 Php、Qt 和 Linux 内核等知名项目。于是他们每天分享一个错误案例，并给出相应建议。今天的案例来自 LibreOffice 项目。
错误代码
BOOL WINAPI DllMain( HINSTANCE hinstDLL,
DWORD fdwReason, LPVOID lpvReserved )
{
....
CreateThread( NULL, 0, ParentMonitorThreadProc,
(LPVOID)dwParentProcessId, 0, &dwThreadId );
....
}
解释：
很久以前，我曾经在业余时间接过一些项目。有一次我就接了一个项目，但是最后没有搞定。这个项目本身就有问题，但是当时我并不知道。更麻烦的是，这个项目乍一看还蛮简单的。
其实就是在 DllMain 方法中，当某些条件触发时，用 Windows API 函数实现一些功能。我记不太清楚要实现哪些功能了，但是肯定不难。
多年以后的今天，我使用 PVS-Studio 开发工具后，我突然意识到当年问题的原因。你瞧，其实 DllMain 函数能正确执行的操作非常有限，因为（很多操作依赖的）DLL 库并没有被加载，所以你不能直接在 DllMain 里就直接执行任意的操作。
我们现在有了诊断工具，可以提醒程序员在 DllMain 里直接用哪些操作是危险的。现在我终于明白那时程序不能运行的原因了。
关于不能在 DllMain 里执行哪些操作的更多细节，可以查看（PVS-Studio）关于 V718 诊断信息的描述。
所以，上面那段 LibreOffice 的代码片段很可能就无法工作。它能不能正常执行完全要靠运气。
正确的代码：
要修复这类错误其实很难。你需要重构整个代码逻辑，让 DllMain 函数里的操作越简洁越好。
建议：
对于这类问题并没有什么特别的建议。你不可能什么都知道，每个人总有一天都会遇到类似的谜题。我认为一个比较普遍的建议是这样的：请仔细地阅读和工作相关的各种文档。但你还是要明白，人们无法预测每一个可能出现的问题。如果你把所有的时间都拿去阅读文档了，那又怎么有时间去编程呢？即使你已经读了很多页的文档，你也不确认有没有漏看了某个文档，而它是可以让你免于犯错的。
我希望能给出更加实用的建议（来避免这些难以捕捉的错误），但是很遗憾我只能想到一条：使用静态分析工具。当然这还是不能保证你就不会犯错了。但是至少这么做会让你犯错的几率降低。如果当年我有了这些工具，那我就绝对不会在 DllMain 里去调用我写的那些代码，那么我很可能就能节省大量时间，少死好多脑细胞。要知道，我对当时没能搞定那个任务一直耿耿于怀！
这个错误由 PVS-Studio 静态分析工具捕获。错误文本：V718：“CreateThread”方法不应该在“DllMain”方法中调用。