私は通常C89でCコードを記述しますが、C99のいくつかの機能（intxx_tまたは__VA_ARGS__またはsnprintf）は非常に便利であり、さらに重要になる可能性があります。
C89からC99までの要件をさらに検討する前に、C99のどの機能が広くサポートされているのか、どの機能が広くサポートされていないのか、あるいは有害であるとさえ考えられているのかを知りたいと思いました。
ターゲットコンパイラのサポートを確認するだけでよいことはわかっていますが、これによりサポートが大幅に狭まります。これはオープンソースソフトウェア用であるため、より幅広いサポートが必要です。
たとえば、Solaris（suncc）コンパイラとgccを使用していますが、わずかな労力で互換性を維持できる一方で、他のコンパイラを邪魔にならないようにする可能性があります。
たとえば、私はWindowsで作業したことはなく、Windowsコンパイラについても何も知りませんが、Windowsの互換性を維持することをお勧めします。
gotoまだ有害であると考えられています。
どういうわけか私は4つの反対票を集めました。私は、妥当性を追加するために上記のステートメントを提示しましたが、その背後にある概念については30％しか真剣ではありません。
反対票はプログラミング言語の歴史を理解していない若者からのものだと思います。すべて が悪であるわけではありませんgotoが、私が取り組んだ100％純粋なスパゲッティコード（数百万行のFORTRAN 66）と比較すると、できるだけ多くのステートメントを構造化されたステートメント（、、、）に置き換えることは合理的でgoto生産for的です。ただし、複数のネストされたループから抜け出すための追加のフラグ変数など、複雑さを回避する場合は、aで問題ない場合があります。whiledo .. whileswitchgoto
ええと、gccは、ターゲットにしているデスクトップOSに関係なく、基本的にgccになります。
Visual C ++は、主にC ++コンパイラであるため、C99仕様にはあまり関心がありません。stdint.hは、お気に入りのintxx_tマクロを宣言します。__VA_ARGS__利用可能です。_Bool、_Complex、および_Pragmaは、Microsoft VisualC++コンパイラには実装されていません。printf / scanfの％aフィールドは実装されていないと確信していますが、VC2010がそれらを処理している可能性があります。snprintfは存在しますが、先頭にアンダースコアがあり、セマンティクスがわずかに異なります。
簡単な答え：C99機能の「簡単な」機能は、コンパイラの文法を変更したり、標準ライブラリを再構成したりせずに実装することです。VC++がそれをサポートする可能性が高くなります。C99とC++の間に競合がある場合は、C++が勝つことを期待してください。
多くのC99機能はオプションであるため、それらの欠如は技術的に不適合ではありません。以下では区別しません。
うーん、winにはありませんが<stdint.h>、Microsoft用のstdint.hのオープンソースバージョンがあります。ファイルが実装されている場合でも、個々のタイプの多くが欠落しています。
複雑で架空のサポートが欠落しているか、壊れていることがよくあります。
拡張識別子とワイド文字が問題になる可能性があります。
gccでのC99機能の問題のこのリストを参照してください。
Runtime sizeof is a nightmare of compiler's writers. So I consider is harmful.
glibcはC99準拠reallocを実装していないため、realloc(ptr, 0)移植性はありません。
restrictC99でキーワードになりました。これは、ユーザーの名前空間を侵害する実装です。という単語を含む有効なC89プログラムがある場合は、restrictC99で動作するようにプログラムを変更する必要があります。言い換えると、下位互換性はありません。下位互換性を損なう場合はgets、最初に標準から削除する必要があります。
のジェネリック数学関数<tgmath.h>は、MacOS X10.6.2のGCC4.2.1で提供されているように見えますが、必ずしも広く実装されているわけではありません。