哪些C99function被视为有害或不受支持
我通常在C89中编写C代码，现在C99的一些function（如intxx_t或__VA_ARGS__或snprintf ）非常有用，甚至可能至关重要。
在我更多地从C89到C99的要求之前，我想知道哪些C99function得到了广泛支持，哪些function得不到广泛支持甚至被认为是有害的。
我知道我们可以检查我们的目标编译器支持，但这会缩小我们的支持范围，因为这是开源软件，我更希望得到更广泛的支持。
例如，我们使用Solaris（suncc）编译器和gcc，但是我们可能会有其他编译器移动，而我们可以通过很少的努力保持兼容性。
例如，我从未在Windows上工作，也不了解Windows编译器，但保持Windows兼容性会很好。
许多C99function是可选的，因此它们的缺乏在技术上不符合要求。 我不会在下面区分。
-
嗯，win没有
-
复杂和虚构的支持经常被遗漏或破坏。
-
扩展标识符和宽字符可以是问题点。
请参阅gcc中的C99function问题列表。
goto仍然被认为是有害的 。
不知怎的，我已经收集了四张选票。 我提出了上面的陈述来增加轻松性，并且对它背后的概念只有30％认真。
我希望下来的选票来自那些不了解编程语言历史的年轻人。 并非每一个单一的 goto都是邪恶的，但是 – 与我曾经研究的100％纯粹的意大利面条代码（数百万行FORTRAN 66）相比 – 用结构化语句替换尽可能多的goto语句是合理且有效的（ for ， while ， do .. while ， switch ）尽可能。 但是有时goto在避免复杂性时很好，例如额外的标志变量可以打破多个嵌套循环。
好吧，无论您要定位哪个桌面操作系统，gcc基本上都是gcc。
Visual C ++主要是一个C ++编译器，并不像C99规范那么关注。 stdint.h确实声明了你最喜欢的intxx_t宏。 __VA_ARGS__可用。 _Bool，_Complex和_Pragma未在Microsoft Visual C ++编译器上实现。 我很确定％printf / scanf中的字段尚未实现，但VC2010可能会处理它们。 snprintf存在，但具有前导下划线和稍微不同的语义。
简短回答：“更容易”的C99function是在不改变编译器语法或重新配置标准库的情况下实现，VC ++更有可能支持它。 如果C99和C ++之间存在冲突，那么期望C ++获胜。
运行时sizeof是编译器编写者的噩梦。 所以我认为是有害的。
glibc没有实现符合C99的realloc ，因此realloc(ptr, 0)不可移植。
restrict成为C99中的关键字。 这是实现侵占用户名称空间的实现。 如果您有一个包含单词restrict的有效C89程序，则必须更改程序以使其适用于C99。 换句话说：没有向后兼容性。 如果他们要打破向后兼容性，他们应该首先从标准中删除。
来自