我在Windows 7上使用VS2013构建对抗2010编译器（我们已经迁移了我们的开发环境，但不是所有项目）。
我真的不知道如何描述这个问题，或者我会谷歌。我有一个指向字节缓冲区的指针，它是我们的有线协议（代码库早于Google及其协议缓冲区）。我们有标题表示id和类型;将指针转换为适当的类型，您可以访问数据，如果数据是动态的，如字符串字段，长度。如果不是有点旧学校，这一切都不应该令人惊讶......
但我所看到的是我有代码检查字段ID - 它应该永远不会为零。但条件是命中，当我检查调试器中的元素时，缓冲区内容和指针位置都是正确的 - 字段是非零的。
所以我向你提问：
1）我怎样才能更好地表达这个问题所以我可以google它？
2）你以前见过这个吗？有任何想法吗？
这是一个很长的镜头，但是，当项目没有正确构建时，我已经看到了它。您可以尝试清理解决方案并重新生成它。
有一些（组合）问题可以像这样出现。
在生产设置中失败的代码，但在调试时单步执行则不然。在这种情况下失败的真正罪魁祸首是，大多数情况下，其他一些不相关的代码滥用指针（并且不应该覆盖内存）。问题是，开发人员获取错误报告，然后使用调试器逐步执行代码。除了使用调试器的事实之外，另一个区别是生产代码是使用某种形式的“完整”优化编译的，而代码是在没有优化（和符号输出）的情况下重新编译的，以供调试器使用。这改变了程序中数据（甚至代码）的内存布局。违规代码仍在骚扰其指针，但内存中的其他内容正在被覆盖。这意味着调试时症状会消失。唯一的解决方法是仔细检查在报告崩溃之前执行的其他代码。
另一种可能性是构建过程已经搞砸了，并且包括过时的函数实现，这些函数表现出旧的bug。尝试做“make clean”和“make build”。
第三种可能性是代码在调试和制作设置中做了不同的事情。例如，有一些代码包含在#ifdef DEBUG ... #endif中，它只在调试时才有效。这种代码通常用于产生“调试输出”。它还会导致程序中内存布局的改变，从而影响指针误操作的症状。
在您描述的场景中，类型转换也可能无效。将char指针投射到指向X的指针时，通常会假设X具有特定大小，这是很常见的。问题是（除了char类型）所有类型的大小都是实现定义的。当使用不同的编译器重建代码时，这种不匹配（例如程序编写流和程序解释它假定差异大小）是一个潜在的罪魁祸首。 [这并不能解释在调试与生产设置中出现和消失的症状，但这是一个可能的原因。]
发现。一个难以看见的分号终止了这个条件;我每次都在打击状态。更好的指针算法纠正了进一步的堆损坏，“realloc（buff，size）”应该是“buff = realloc（buff，size）”。