这样潜伏在代码深处的bug简直是一个噩梦。我相信这仅仅是个失误，但无论是谁手滑（手贱）把这样的代码写出来，我都为他感到深切的悲痛。
　　下面是一段和这个bug有相同问题的代码：
extern int f();
int g() {
int ret = 1;
goto out;
ret = f();
out:
return ret;
}
　　如果我编译时候加上参数-Wall（启用所有警告），在Xcode中无论是GCC 4.8.2还是Clang 3.3都没有对死代码发出警告，对此我非常惊讶。更好的编译警告本可以阻止这样的悲剧，又或许在实际编码中这类警告发生第一类错误（弃真错误）的概率太高？（感谢Peter Nelson指出在Clang可以使用-Wunreachable-code参数对这样的问题发出警告，而不是-Wall。）
　　看起来是允许if代码块不使用大括号才导致了这样的代码风格，但是有人在大括号里也可能使用错误的代码缩进，因此我也没觉得大括号带来了多少便利。
　　写一个测试用例本可以发现这个问题，但是由于它深嵌在连接握手的过程中，所以非常复杂。这个用例需要写一个完全独立的TLS栈，并且包含大量发送无效握手请求的配置。在Chromium中我们有个修改过的TLSLite工具可以做类似的测试，但是我不太记得我们的用例是否完全适用于这个bug的情况。（如果不行的话，听起来好像我已经知道周一早上要干嘛了）（译注：当然是把用例改到可以完全适用）
　　代码审查对发现这类bug非常有效。不仅仅是浏览审阅，而是审查每句新写的代码。我不知道苹果一般怎么做代码审查，但是我充分相信我的同事，Wan-Teh和Ryan Sleevi。如果我意外手滑，他们一定会及时发现。可惜不是每个人都有幸和这样的同事一起工作。
　　近，针对苹果忽略对证书中主机的校验这个事情，有一系列讨论。的确在OS X中使用curl时，即使IP地址不在证书中，命令行也会接受和这个主机的连接。然而我没找到更多问题了，Safari也没有受到影响。