事出在这段代码。。。
问题出在最下面的 wait。
竟然给我报了个警告，啥意思，说那个傻逼句柄可能是个空的。
真有意思，空不空，你管得着么，我就想这么写，但是没办法。
人家报警告了，本着一个安全开发的角度，警告都是视为错误的，处理呗。
处理好办，让它不为空就好了呗，咋不为空，就是加上58行的判断，
如果为空滚蛋，那么剩下的就不为空了呗。
解了58行的注释后，它还真的就神奇地没警告了。
然后来吧，开始翻为啥有这个警告呗。
这玩意说不符合函数要求，它有啥要求，去查。
原型就这逼样，继续进去查。
我看到了一个比较可疑的东西，就是这玩意。
为啥我说这个可疑呢，因为，回去看 CreateEventW 的声明。
这标记已经说明白了，这个返回值可能是个null。
然后目标函数还要求不许是null。
中间我没判断这玩意的返回值，所以就警告了。
找谁说理去。
挺好玩的吧。
但是问题来了，从这一个点，能看出什么，
首先，VS支持基于标记的静态代码审计。
其次，VS可能支持基于上下文的静态代码审计。
甚至有可能，VS支持代码模拟执行（符号执行一类）。
但是，这本身就是个死循环，或者是个死路。
比如，我就想这么用，而且我确定这是没问题的，
编译器你给我报了个警告，你什么意思。
一点不干，不好意思，
干得太多，你什么意思？
只能干点，意思意思？
这日子过的。
不到万不得已，我是没兴趣去屏蔽警告的，
毕竟人家是来帮忙的，干嘛要屏蔽它，
但是这种，咋整。
但是，话说回来，基于标记的静态代码审计，应该是个趋势了，
C++的静态代码审计其实是困难重重的，（自动化审计啊），
各种点，都是问题，（用过 cppcheck ，写个cppcheck的功能，就知道C++代码审计多难了），
要考虑的东西特别多。一个数组传个十几层函数，可能到最后开发都不知道它是干啥的，
开发都不知道它啥时候可能会崩，你让一个程序跑出来结果，预测它啥时候会崩，
这不是纯粹扯蛋么。
这种标记，算是开发人员在开发时，告诉编译器这个东西是什么，
然后编译器去检查这个东西是否有按照要求来用就好了。其实挺不错的。
出发点很不错，方法也很好，但是问题在于，
我们要做一个功能还好说，但是如果我要做个框架，我无法预期后人如何使用我的框架，
然后怎么办，我留出来的接口、回调、监视点、功能点，可能全都会出现这种问题。
感想：
不能再总用2005了，该换了。
总结：
微软很牛逼，走别人的路，让别人无路可走。
睡觉。