Clever Geek Handbook

Cが間違いを止めない理由



要するに：私たちがそう言ったからです。



:)



さて、これは記事、親愛なる読者のための説明が短すぎます、そして私の挑発的な言葉は説明を必要とします。



もともとドイツのフライブルクで開催される予定だったが、明らかな理由で一緒に成長しなかったC言語委員会の会議は8月7日に終了しました。それはうまくいき、私たちはあらゆる面で進歩を遂げました。はい、私たちは確かに進歩しています、私はあなたに保証します、そしてCは死んでいません。



また、私がCプロジェクトの編集者になったので、「改善しよう」と怠惰な人からの無知な発言としてタイトルをとる前に、Cができるように実際に非常に懸命に取り組んでいることを保証したいと思います。多かれ少なかれ美しくて便利なライブラリとアプリケーションを構築するために、50の特定の拡張機能をねじ込むことなく、開発者のニーズを満たすため。



それでも私はそれを言いました（C言語はあなたが間違いを犯すことを決して止めないでしょう）、それは私が正当化する必要があることを意味します。何千ものCVEと関連するチケットを、一連のCコードで確認することも、MISRAにすべてのC機能の誤用の可能性を精力的にチェックさせることもできます（こんにちは、K＆Rプロトタイプ宣言）。...）または、移植性と未定義の動作に関連する、より複雑で面白いバグがあります。しかし、代わりに、元の情報源、つまり委員会自体が言ったことを読みました。



ああ、ポップコーンを手に入れる時が来たの？



親愛なる読者はいません、ポップコーンを脇に置いてください。すべてのISO手順と同様に、私は他の人の言葉を引用することはできません。また、この記事は誰かを恥じることを意図したものではありません。しかし、標準に準拠したISOCドキュメントで不正な動作を簡単に考慮できるものが除外されない理由を説明します。そして、Philipp Klaus Krause博士による文書から始めましょう：



N2526、変更されないライブラリデータにはconstを使用します。



N2526は非常に単純なドキュメントです。



, , , . — , ! …


私は同意します、それはまったく同じことではありません、しかし私はその考えがあなたにとって合理的であるように思われると確信しています、親愛なる読者。この文書が投票されたとき、反対票はほとんどありませんでした。その後、この提案が古いコードを破ったため、何人かの人々が強く反対しました。もちろん、これは悪いことconstです。追加することを考えると、息を呑むことさえありますか？イノベーションの影響を受ける可能性のあるC言語のABIはありません。C（その実装）は修飾子にも注意を払っていませんが、どうすれば何かを壊すことができますか？！これが重大な変化になると考える人がいる理由を見てみましょう。



言語C



または、私がそれを呼びたいように、「タイプの安全性は失敗した言語のためのものです」。はい、冗長すぎるので、「C」で停止しましょう。Cのような言語はタイプセーフではないと私が言うのはなぜか疑問に思われるかもしれません。結局のところ、ここにあります： 



struct Meow {
    int a;
};

struct Bark {
    double b;
    void* c;
};

int main (int argc, char* argv[]) {
    (void)argc;
    (void)argv;

    struct Meow cat;
    struct Bark dog = cat;
    // error: initializing 'struct Bark' with an expression of incompatible type 'struct Meow'

    return 0;
}


正直なところ、これは私には強いタイプの安全のように見えます、ジム！そして、すべてがさらに厄介になります。 



#include <stdlib.h>

struct Meow {
    int a;
};

struct Bark {
    double b;
    void* c;
};

int main (int argc, char* argv[]) {
    (void)argc;
    (void)argv;

    struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
    struct Bark* p_dog = p_cat;
    // :3
    
    return 0;
}


はい、C標準では、2つの完全に独立したポインタータイプが相互に参照できます。ほとんどのコンパイラはこれについて警告しますが、標準では-Werror -Wall -Wpedantic、巻き戻しなどを行わない限り、このコードを受け入れる必要があります。



実際、コンパイラは明示的なキャストなしでこれを受け入れることができます。



  • volatile （誰がこれらのセマンティクスを必要としますか？！）
  • const （ここに読み取り専用データを書き込んでください！）
  • _Atomic （スレッドの安全性！）


私はあなたがこれらすべてを行うことができないはずだと言っているのではありません。しかし、Cで書くと（完全に理解できない変数名で500〜1000行の関数を作成するのは非常に簡単です）、Infa Sotkaは、主にポインターを操作し、一般に基本言語のセキュリティが不足しています。注：これは制限に違反しますが、非常に多くの古いコードが既に記述されているため、すべての実装で修飾子が無視されます。このため、コードのコンパイルが妨げられることはありません（@fanfに感謝します）。）！この状況では、コンパイラーを使用してすべての潜在的な障害を簡単に識別でき、警告が表示されますが、コンパイラーに本当にやりたいことを知らせるためにタイプキャストする必要はありません。しかし、もっと重要なことは、あなたの後に来る人間もあなたが何をしようとしているのか理解できないでしょう。



この機能を削除する-Werror -Wall -Wpedanticだけで、マルチスレッド、読み取り専用モード、およびハードウェアレジスタの犯罪を犯す準備が整います。



今はすべて公平ですよね？誰かがこれらの警告フラグとエラーフラグをすべて削除した場合、彼らはあなたがどんな種類の失敗や愚かなことをしたかを気にしません。これは、最終的に、これらの警告は、ISO C準拠に関する限り、完全に無関係で無害であることを意味します。それでも...



警告を破ることを検討しています



はい。



これは、C開発者と、それほどではありませんがC ++開発者が慣れている特別な地獄です。警告は煩わしいものであり、実践が示すように、-Weverythingまたはを含めて/W4、非常に迷惑です。グローバルネームスペースで変数の警告を非表示にし（おかげで、すべてのヘッダーとCライブラリが問題になりました）、「予約済み」の名前を使用し（子供たちが言うように、「lol nice one xd !!」）、「この構造にはパディングがありますあなたがalignof「（...はい、はい、彼女がパディングを持っていることを知っています、私が使用したので、私は明示的にもっとパディングを求めました、MR。COMPILATOR alignof）-これはすべて時間がかかります。



しかし、これらは警告です。



煩わしい場合でも、問題を回避するのに役立ちます。恥知らずにすべての修飾子を無視し、あらゆる種類の読み取り、書き込み、ストリーム、および読み取り専用のセキュリティを無視できるという事実は、私の意図を伝え、バグを回避する際の大きな懸念事項です。古いK＆R構文でさえ、ユーザーが何か間違ったことをしているため、産業および政府のコードベースにバグをもたらしました。そして、彼らがこれをしたのは、彼らがお粗末なプログラマーだったからではなく、彼らよりも古いことが多いコードベースで作業し、それらと戦う準備をしているからです。何百万もの長い行。コードベース全体を頭の中に保持することは不可能です。規則、静的分析、高レベルの警告、およびその他のツールがこれに対応します。残念ながら、



誰もが警告なしのコードを持ちたいと思っています。



つまり、GCC開発者が潜在的に問題のある状況に対して警告をより敏感にすると、メンテナ（元の開発者ではない）は、多くの新しい警告やあらゆる種類のさまざまなものを含む、古いコードから数ギガバイトの太字のログを予期せず受信します。 「これはばかげている」と彼らは言う。「コードは何年も機能したのに、なぜGCCは今不平を言っているのですか？」つまりconst、署名に機能を追加しても、道徳的、精神的、実際に正しい場合でも、これは回避されます。 「壊す」ということは、「今、彼らは疑わしい意図を持ったコードを探さなければならない」という意味です。これは、未定義の動作の痛みで、チップを破壊したり、メモリを損傷したりする可能性のあるコードです。..。しかし、これは最近のC開発者の職業に伴うもう1つの問題です。



品質の尺度としての年齢



sudo「-1または整数のオーバーフローはすべてにアクセスできる」などの原始的な脆弱性があると思った 人は何人いますか？ Heartbleedが本当の問題になると思った人は何人いますか？フェーザーを使用せず、これらのライブラリに想像以上に重要な入力の脆弱性が含まれていることに気付かずに、「小さな」stbライブラリを出荷するゲーム開発者は何人いますか？私はこれらの開発やその作者のすべてを批判しているわけではありません。彼らは私たちに重要な助けを提供します。しかし、これらの開発を偶像化し、それを自分で置く人々は、その後、生存者の過ちを説明する、彼ら自身からの有毒な発言をにじみ出させます。



, ?


後方互換性の原則を維持し、Cの最高の理想として「リラックス」することで、この業界で十分長く生き残る人々は、コードベースがワインの樽であるように、年齢と品質を同一視し始めます。コードが古くて長く使用されるほど、ワインはより細かく、より洗練されます。



残念ながら、すべてがそれほどロマンチックでかわいいわけではありません。バグがたくさんあり、セキュリティホールがたくさんあるため、この技術的な負債はすべて毎日ますます危険になっています。時間の経過とともに、すべてのシステムは半減期で、空っぽで、部分的にサポートされていない腐敗した山になります。彼らは装飾され、高貴な精神を与えられていますが、実際には彼らはぎこちなく突かれるのを待っているミイラです、そして彼らの猛烈な、前衛的な膿瘍は爆発し、あなたのアプリケーションを彼らの美しい、老化したボツリズムで溢れさせます。



うーん...嫌です。しかし、標準Cはどうですか？



会議の参加者としての（信じられないほど短い）在職中に気付いた問題は、後方互換性を前面に置いていることです。今日でもCに移行している人のために、私たちは古いアプリケーションとその使用例を保持し、Cコードの安全性、セキュリティ、または芸術性を向上させる機会を奪っています。 、彼はそれらをオフにすることができます。エラーではなく、これらの警告は無駄ではありません。抽象Cマシンは必要ありません。診断を行うために、ISO Cでは、そのようなコードを厳密なアセンブリモードで受け入れることができます。そしてそれは、「私たちが提供するコンテンツを変更することは未定義の動作です」と公然と述べているAPIから全世界が脱却するのに役立ちます。



しかし、「新たな警告を導入できない」という理由でこの文書について考えを変えました。



提案に反対する議論は、「これらの署名を変更すると壊れてしまうコードがたくさん書かれている」というものでした。これもまた、動作を壊すという観点から警告への変更を制限します（修飾子を削除する暗黙の変換であることを忘れないでください。_Atomic-制限に違反している場合でも、ISO Cに従って完全に有効です）。その場合、すべてのコンパイラ作成者は、Ages in Rust、For Warnings Onlyなどを導入して、テスト用の「安定した」ベンチマークを提供します。この提案は新しいものではありません。新しいアラートの生成とユーザーの反応について、Coverityエンジニアから同様のドキュメントを読みました。新しい警告などに関する開発者の「自信」を管理することは困難です。人々に彼らの有用性を納得させるには長い時間がかかります。 John Carmackでさえ、「これを使用しないのは無責任である」と結論付ける前に、彼の開発に合わせて静的分析ツールから適切な警告とエラーのセットを取得するために一生懸命努力しなければなりませんでした。



それでも、委員会は、const潜在的に危険なコードに警告を追加するため、4つの関数に値を返す関数を追加することに同意しませんでした。間違ったタイプを渡すことによる無実の見落としと深刻な脆弱性の両方の強力な証拠にもかかわらず、古いK＆R構文が非推奨になることに反対しました。私たちはしましほとんどちょうどそれを得るために、しかし、Cの実装にするために、プリプロセッサに未定義の動作を追加した「それが必要として動作します。」後方互換性があるため、明らかな間違いをしないように、常にエッジを歩きます。そして、これは、親愛なる読者の皆さん、Sの将来について私を最も怖がらせます。



標準Cはあなたを保護しません



間違いありません。プログラマーがあなたに何を言っても、何をささやいても構いません。 C言語運営委員会は非常に明確です。このコードが危険である可能性がある場合でも、古いコードに新しい警告を追加することはありません。古いコードがどのように機能するかという考えを損なう可能性があるため、間違いを犯すことを妨げることはありませんが、それは間違っています。初心者がより良いCコードを書くのを手伝うことはありません。古いコードが標準に準拠する必要はありません。コンパイラの作成者に高い標準に固執することを強制したり、標準のライブラリ開発者にもっと期待したりすることは想像できないため、各新機能はオプションになります。



コンパイラーをあなたに任せます。私たちはあなたのコードに嘘をつきます。そして、すべてがうまくいかないとき-「ああ、ある種のゴミが起こった」というエラーが発生し、データリークが発生します-私たちは厳粛に首を横に振るでしょう。私たちは私たちの考えを共有し、あなたのために祈って、「まあ、なんて残念だ」と言います。確かに、残念です...



おそらくいつか私たちはそれを修正するでしょう、親愛なる読者。


More articles:


All Articles