C++11 の最新のドラフトに基づいて、C++ は、C ライブラリ関数の定義について ISO/IEC 9899:1999/Cor.3:2007(E) を参照します (§1.2[intro.refs]/1 による)。 .
C99 TC3 の最新のドラフトに基づくThe gets function is obsolescent, and is deprecated.
(§7.26.9/2 による)
gets()
これは C と C++ の両方で推奨されていないと言えますか?
C++11 の最新のドラフトに基づいて、C++ は、C ライブラリ関数の定義について ISO/IEC 9899:1999/Cor.3:2007(E) を参照します (§1.2[intro.refs]/1 による)。 .
C99 TC3 の最新のドラフトに基づくThe gets function is obsolescent, and is deprecated.
(§7.26.9/2 による)
gets()
これは C と C++ の両方で推奨されていないと言えますか?
非推奨とは、使用すべきでないことを意味し、将来削除される可能性があります。どちらの標準も非推奨であると述べているため、公式には非推奨であることを意味します。
それは問題ですか?使用できる唯一の方法は、内容を完全に制御できるファイルに添付されていることがわかっているgets
場合です。stdin
この条件を満たすことはほとんど不可能です。特に、他のプロセスがプログラムに対して非同期にファイルを変更する可能性があるマルチプロセス システムではそうです。したがって、すべての実用的な目的のために、使用するプログラムgets
は未定義の動作を持ち (つまり、未定義の動作をする可能性のある入力/環境条件があります)、特に UB は、プログラムがより高い特権を持っている場合に特権の侵害につながる可能性があります。データの提供者。
編集: OK、これが の安全な使用法ですgets
。私がすぐに思いつく唯一のものについて...
if (feof(stdin)) gets(buf);
もちろん、一部のバグのある実装 (おそらく glibc..? を含む) では、ストリームに EOF インジケーターが既に設定されている場合でも読み取りが許可されます。
ライブラリから gets() を削除することで破損するコードでさえ、そのような削除後は、そのような削除前よりも壊れにくくなります。コンパイラのベンダーが「完全に標準に準拠した」モードに含める必要があるかもしれないと思いますが、安全に使用できる状況の数は非常に少ないため、「通常のモード」から除外するのがおそらく妥当でしょう。 " 建てる。
C++11 がどこにでも実装されるまでには、しばらく時間がかかります。
また、ほとんどのコンパイラはまだ C99 を完全にサポートしていません。
たとえば、マイクロソフトはそうではありません。
いいえ、C と C++ の両方で廃止されていません。