我通常用 C89 编写 C 代码，现在 C99 的一些特性（如intxx_tor__VA_ARGS__或snprintf）非常有用，甚至可能是至关重要的。
在我将我的要求从 C89 扩展到 C99 之前，我想知道哪些 C99 功能得到了广泛支持，哪些没有得到广泛支持，甚至被认为是有害的。
我知道我们可以只检查我们的目标编译器支持，但这会大大缩小我们的支持范围，因为这是针对开源软件的，所以我希望获得更广泛的支持。
例如，我们使用 Solaris (suncc) 编译器和 gcc，但我们可能会移除其他编译器，同时我们只需很少的努力就可以保持兼容性。
例如，我从来没有在 Windows 上工作过，我也对 Windows 编译器一无所知，但保持 Windows 兼容性会很好。
goto仍然被认为是有害的。
不知何故，我收集了四张反对票。我提出上面的陈述是为了增加轻率，并且对它背后的概念只有 30% 的认真。
我预计反对票来自不了解编程语言历史的年轻人。并非每一个 goto都是邪恶的，但是——与我工作过的 100% 纯粹的意大利面条代码（数百万行 FORTRAN 66）相比——goto用结构化语句 ( for, while, do .. while, switch) 替换尽可能多的语句是合理且富有成效的。但有时 agoto在避免复杂性时就很好，例如额外的标志变量以打破多个嵌套循环。
好吧，无论您的目标是哪个桌面操作系统，gcc 基本上都是 gcc。
Visual C++，主要是一个 C++ 编译器，不太关心 C99 规范。stdint.h 确实声明了您最喜欢的 intxx_t 宏。__VA_ARGS__可用。_Bool、_Complex 和 _Pragma 未在 Microsoft Visual C++ 编译器上实现。我很确定 printf/scanf 中的 %a 字段尚未实现，尽管 VC2010 可能会处理它们。snprintf 存在，但有一个前导下划线和稍微不同的语义。
简短的回答：C99 功能的“更容易”是在不更改编译器语法或重新检测标准库的情况下实现，VC++ 更有可能支持它。如果 C99 和 C++ 之间存在冲突，那么期待 C++ 获胜。
许多 C99 功能是可选的，因此它们的缺失在技术上并非不符合标准。下面我就不区分了。
嗯，win 没有<stdint.h>，虽然微软有 stdint.h 的开源版本。即使实现了文件，也缺少许多单独的类型。
复杂和虚构的支持经常丢失或损坏。
扩展标识符和宽字符可能是问题点。
运行时 sizeof 是编译器编写者的噩梦。所以我认为是有害的。
glibc 没有实现符合 C99 的realloc，因此realloc(ptr, 0)不可移植。
restrict成为 C99 中的关键字。那是侵犯用户命名空间的实现。如果您有一个包含单词 的有效 C89 程序，则restrict必须更改您的程序以使其与 C99 一起使用。换句话说：没有向后兼容性。如果他们要破坏向后兼容性，他们应该gets首先从标准中删除。
类型通用数学函数<tgmath.h>不一定广泛实现，尽管它们似乎在 MacOS X 10.6.2 上随 GCC 4.2.1 提供。