問題タブ [tr24731]

ISO C 委員会 ( ISO/IEC JTC1/SC21/WG14 ) はTR 24731-1を発行し、 TR 24731-2に取り組んでいます。

TR 24731-1: C ライブラリの拡張 パート I: 境界チェック インターフェイス

WG14 は、より安全な C ライブラリ関数に関する TR に取り組んでいます。この TR は、多くの場合、バッファー長にパラメーターを追加することによって、既存のプログラムを変更することを目的としています。最新のドラフトはドキュメント N1225 にあります。根拠はドキュメント N1173 にあります。これはテクニカル レポート タイプ 2 になります。

TR 24731-2: C ライブラリの拡張 - パート II: 動的割り当て関数

WG14 は、より安全な C ライブラリ関数に関する TR に取り組んでいます。この TR は、バッファー長の追加パラメーターの代わりに動的割り当てを使用する新しいプログラムを対象としています。最新のドラフトはドキュメント N1337 にあります。これはテクニカル レポート タイプ 2 になります。

質問

• TR24731-1 関数をサポートするライブラリまたはコンパイラを使用していますか?
• もしそうなら、どのコンパイラまたはライブラリで、どのプラットフォームで使用されていますか?
• これらの関数を使用するようにコードを修正した結果、バグが見つかりましたか?
• 最も価値のある機能はどれですか?
• 値がない、または負の値を提供するものはありますか?
• 今後図書館を利用する予定はありますか？
• TR24731-2 の作業を追跡していますか?

scanf_s() に奇妙な点があることは知っていますが、問題を解決できませんでした。私のコードは scanf() を使用してうまく機能しますが、これは配列の要素を逆にしません:(

いわゆる安全なライブラリの deprecations について尋ねた以前の質問の型では、なぜfopen()deprecated にする必要があるのか​​ について同様に困惑しています。

この関数は 2 つの C 文字列を取り、FILE* ptr を返すか、失敗すると NULL を返します。スレッドセーフの問題/文字列オーバーランの問題はどこにありますか? それとも別のものですか？

前もって感謝します

次のコードはエラーを引き起こし、アプリケーションを強制終了します。バッファーの長さはわずか 10 バイトで、テキストの長さは 22 バイトであるため (バッファー オーバーフロー)、これは理にかなっています。

アプリケーションをクラッシュさせずに報告できるように、このエラーをキャッチするにはどうすればよいですか?

編集：

以下のコメントを読んだ後、_snprintf_s を使用しました。-1 値を返す場合、バッファは更新されていません。

を使用する C プログラムがありますsprintf_s。Windows では問題なく動作しますが、Linux でコードをコンパイルすると、次のエラーが発生します。

なぜこれが起こり、どうすれば修正できますか?

コードでこれらのワイド文字リテラルを使用して、それらについて学習しています。

なぜ私はこれらの警告を受け取っているのですか、とにかくそれを無視しました。そのような警告を無視する必要がありますか？

これは私の最初の投稿であり、認めざるを得ません。プログラミングがひどいです。私はクラスのその男であり、彼の尻尾を切り落としていますが、他のクラスメートと同様にプログラミングを理解しているようには見えません。よろしくお願いします。以下で私の問題を説明しようと思います。

次のコード（コメントは削除されています）がありますが、実行すると、以下のような警告が表示されます。また、プログラムを実行すると、最初のユーザー入力値が許可されますが、突然、プログラムの最後にジャンプし、他の変数（変数「ベータ」など）の値を入力できなくなります。 ）。出力の画像（http://i.stack.imgur.com/yc3jq.jpg）があり、アルファを入力したことがわかりますが、プログラムは最後まで実行されます。何かご意見は？

どうもありがとうございました！-スペンサー

- - - - - - - - - - - - - - -コード - - - - - - - -

警告の例：

C と C++ が混在する古いプロジェクトがあります。strcpyC 文字列や、strcat、などを広範囲に使用します。多くのバッファ オーバーフローを発見したのでstrncpy、. MSVC にはこれらの機能が含まれていますが、少なくとも Linux、OSX、および Windows など、さまざまなプラットフォームで動作するものが必要です。strncatstrcpy_s

私は知っていますstrlcpyが、多くの人が指摘しているように ( example )、実際には改善されていません。

strcpy_sでは、strcat_s、 など、または 全体の無料の実装はありTR24731-1ますか?

またはのいずれかpublic domainが必要BSDですが、他のライセンスの下での実装を知っている場合は、先に進んでリストしてください。他の誰かが恩恵を受けると確信しています。

1. GNUではMicrosoftCランタイムと同じように非推奨ですか？

2. GNU Cにそのようなものがある場合、非推奨は89/90以降のCの標準またはコンパイラによって強制されますか？

3. GNU Cコンパイラの場合、Microsoft Cmemcpy_sで非推奨になったような、安全な代替メモリ操作機能をいつ、どのように提供するのでしょうか。memcpy

4. 89/90以降のC標準の場合、Microsoft Cmemcpy_sで非推奨になったような、安全な代替メモリ操作機能をいつ、どのように提供するのでしょうか。memcpy

5. GNU Cランタイムにそのような非推奨がない場合、それらのメモリ操作（名前はで始まるmem）にも私が知っているものにも含まれない関数はありbcopyますが、長さに関するパラメータを受け取るという点でメモリを安全にコピーするために使用できます行き先？

6. ある/ある場合、できるだけ多く挙げていただけますか？

次のコマンドを使用して、Ubuntu 4.6.1 および SUSE 4.6.2 で gcc を使用しています。

私のソースコードは

私の質問について詳しく説明します。

私にとっての主な問題は、入力された行と保存された行の間の 1 対 1 の対応です。

成功した場合、fgets と gets_s の違いは、fgets には改行ターミネータが含まれているのに対し、gets_s は改行ターミネータを null ターミネータに置き換えて、行入力と gets_s への成功した呼び出しとの間の 1 対 1 の対応を維持することです。

バッファー長をオーバーフローする入力の場合、fgets はバッファーに収まる数の文字を受け入れ、残りを次の fgets のために入力バッファーに残します。

標準 (K.3.5.4.1) では、(gets とは異なり) gets_s を使用する場合、改行、EOF、または n-1 文字以内の読み取りエラーが必要であると規定されています。したがって、オーバーフローは実行時制約違反です。実行時制約違反がある場合、バッファ内の最初の文字がヌル文字に設定され、stdin 入力バッファ内の文字が読み取られ、改行文字が読み取られるまで破棄されます。ファイルの終わりが発生します。または読み取りエラーが発生します。

したがって、成功した場合、私は次のことを期待しました。

オーバーフローでは、fgets と gets_s とは異なる動作を期待していました。言い換えると、

gets_s が入力の最初の行の内容を完全に削除することを期待していたことに注意してください。

主な問題が入力行と保存行の間の 1 対 1 の対応である場合、これはデバッグにおいて重要ですが、独自の関数を記述する必要があります (K&R の getline と同様)。

このような関数では、1 対 1 の対応が維持され、バッファが飽和し​​、実行時制約違反は発生しません。

この結論を導き出すことは正しいでしょうか。