C99标准有什么意义？

C99为该语言添加了一些有用的function，但我发现很难推荐任何依赖于C99的练习。这是因为C99语言的实际实现很少（任何？）。当然，在一些编译器中支持有限，但没有人愿意花时间编写C代码只是为了让它不可移植。

考虑到该标准是在10年前编写并最终确定的，这令人沮丧。另外，我不时会听到有关C1x的讨论，我想知道为什么有人会采取措施修改语言，因为当前版本的语言尚未实施。

所以我的问题是，作为乔今天的C程序员，我对C99标准有什么用处（如果有的话）？

MSVC不会，也不会支持C99。但微软几乎没有动力更新他们的C编译器。这并不是说他们会失去太多的业务。

但是有很多编译器都支持C99。

关于gcc：

你是对的，或许C99对于库代码没有用（并且可能永远不会没有微软的支持），但如果你正在从事内部或个人项目，你可以选择编译器和工具，那么可移植性不是很多问题。

C99带来的function确实使C语言编程更容易，更安全：

语言也更具表现力

在我的linux机器上，我有四个支持C99的编译器达到令人满意的程度，使其可以在日常基础上使用： gcc ， clang ， opencc和icc 。

前两个是开源编译器，其中clang试图与gcc代码兼容（意味着C99支持大致相同）。

后两者来自两个主要的CPU生产商，并且是商业性的，但对非商业用户有慷慨的许可政策。他们的C99有点少，特别是他们inline的支持似乎与标准不完全一致。

关于C1x，我认为值得注意的是，标准委员会非常清楚C99尚未被广泛采用，并且不想重复相同的错误（或使情况更糟）。从C1x章程：

与C9X不同，伦敦会议的共识是没有任何发明，毫无例外。只应考虑具有历史记录且商业实现常用的function。此外，必须注意以一种使标准和商业实现兼容的方式标准化这些function。

和：

最初的标准得到了用户和供应商社区的积极响应。但是，C99并没有得到广泛接受。

每当您没有锁定在不支持C99的环境中时（尤其是嵌入式系统），您应该使用C99。

是的，如果您知道您的库将被使用MSVC的人使用，您不能在接口中使用C99function，但没有理由不在实现中使用C99（当然除了库function依赖性之外））。

原始答案：“呃？哪些编译器不支持C99？当你从编译器转到工具时，C99实际上比C89更受支持。”

如果你关心表现，就没有办法restrict 。

FreeBSD现在使用Clang进行内核编译，而且几乎支持C99。