[解決済み] TR 24731の「安全な」機能を使用していますか？[クローズド］

質問

ISO C委員会( ISO/iec jtc1/sc21/wg14 ) が発表した TR 24731-1 を発行し TR 24731-2 :

TR 24731-1: Cライブラリの拡張 Part I: Bounds-checking interfaces

WG14は、より安全なCライブラリ関数に関するTRに取り組んでいる。このTRは，既存のプログラムを修正することを指向しており，しばしば，バッファ長で追加のパラメータを追加する。最新の草案は、文書N1225にある。その根拠は文書N1173にある。これは技術報告書タイプ 2 になる予定である。

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

WG14は、より安全なCライブラリ関数に関するTRに取り組んでいる。このTRは，バッファ長のための追加パラメータの代わりに動的割り当てを使用する新しいプログラムに向いている。最新のドラフトは文書N1337である。これは技術報告書タイプ 2 になる予定である。

質問事項

• TR24731-1関数をサポートしたライブラリやコンパイラを使用していますか？
• 使用している場合、どのコンパイラまたはライブラリで、どのプラットフォームで使用していますか？
• これらの関数を使用するようにコードを修正した結果、何かバグを発見しましたか。
• どの関数が最も価値を提供していますか？
• 価値のないもの、またはマイナスの価値を提供するものはありますか？
• 将来的にライブラリーを利用する予定はありますか？
• TR24731-2 の作業を全く追跡していないのですか？

どのように解決するのですか？

私は、これらの TR が始まったとき (単一の TR だったとき) から声高に批判しており、私のソフトウェアでは決して使用しません。 これらの TR は原因に対処する代わりに症状を覆い隠し、同じ目標をはるかに効果的に達成できる既存のプラクティスを促進する代わりに誤った安心感を与えるので、どちらかといえばソフトウェア設計にマイナスの影響を与えるというのが私の意見です。 私は一人ではなく、実際、これらの TR を開発する委員会以外の主要な提案者を一人も知らないのです。

私は glibc を使っているので、glibc のリードメンテナである Ulrich Drepper のように、この無意味なことに対処するのを免れることができると思います。 はこの話題について :

提案されているsafe(r) ISO Cライブラリ は、この問題に完全に対処できていません。 ... プログラマの生活をさらに難しくする提案は プログラマの生活をさらに困難にすることを提案しても 助けにならない。 しかし、これこそが提案されていることなのです が提案されているのです。... これらはすべて、より多くの作業を必要とするか する必要があるか、あるいは単に 愚かなものです。

彼は、提案された多くの関数の問題点を詳しく説明し、glibc が決してこれをサポートしないことを他の場所で指摘しています。

Austin Group (POSIXの保守を担当) は、このTR、彼らのコメント、委員会の回答について、非常に批判的なレビューを提供している。 ここで . Austin Groupのレビューは、TRの問題の多くを非常にうまく詳述しているので、ここでは個々の詳細には触れません。

つまり、結論は 私はこれをサポートする、またはサポートする予定の実装を使用しておらず、これらの関数を使用する予定もなく、TR には何の正の価値も見いだせません。 私は個人的には、TRがまだどんな形であれ生きている唯一の理由は、広範な反対にもかかわらず標準化委員会に物事を突っ込ませる能力があることを最近証明したMicrosoftによって、強く推されているからだと考えています。 もしこれらの関数が標準化されたとしても、この提案は数年前からあり、コミュニティの真の支持を集めることができなかったので、広く使われることはないと思う。