Clang / LLVMが、列挙されたすべてのケースが含まれるswitchステートメントでデフォルトを使用することについて警告するのはなぜですか？

次のenumおよびswitchステートメントを検討してください。

typedef enum {
    MaskValueUno,
    MaskValueDos
} testingMask;

void myFunction(testingMask theMask) {
    switch (theMask) {
        case MaskValueUno: {}// deal with it
        case MaskValueDos: {}// deal with it
        default: {} //deal with an unexpected or uninitialized value
    }
};

私はObjective-Cプログラマですが、より多くの読者のために純粋なCでこれを書いています。

-Weverythingを使用したClang / LLVM 4.1では、デフォルトの行で警告が表示されます。

すべての列挙値をカバーするスイッチのデフォルトラベル

今、私はこれがなぜあるのかを見ることができます：完全な世界では、引数に入力する値theMaskは列挙型のみであるため、デフォルトは必要ありません。しかし、ハックがやって来て、初期化されていないintを美しい関数に投げ込んだらどうなるでしょうか？私の機能はライブラリのドロップとして提供され、そこに何が入るかを制御することはできません。を使用することdefaultは、これを処理する非常に適切な方法です。

なぜLLVMの神は、この振る舞いを地獄のデバイスにふさわしくないと考えているのでしょうか？引数をチェックするifステートメントをこれに先行させる必要がありますか？

以下に、clangのレポートの問題も、保護している問題も発生していないバージョンを示します。

void myFunction(testingMask theMask) {
    assert(theMask == MaskValueUno || theMask == MaskValueDos);
    switch (theMask) {
        case MaskValueUno: {}// deal with it
        case MaskValueDos: {}// deal with it
    }
}

Killianは、clangが警告を発する理由をすでに説明しています。enumを拡張した場合、デフォルトのケースに陥ります。正しいことは、デフォルトのケースを削除し、未処理の状態に関する警告を取得することです。

ここで、誰かが列挙外の値を使用して関数を呼び出すことができるのではないかと心配しています。これは、関数の前提条件を満たしていtestingMaskないように思えます。列挙から値を期待することが文書化されていますが、プログラマは何か他のものを渡しました。そのため、（または、Objective-Cを使用していると言ったように）プログラマーのエラーを使用してください。プログラマーが間違っている場合、プログラマーが間違っていることを説明するメッセージでプログラムをクラッシュさせます。assert()NSCAssert()

持ってdefaultここにラベルすることは、あなたが期待しているかについて混乱していることの指標です。あなたはすべての可能使い果たしてしまったのでenum、明示的な値を、defaultおそらく実行できない、とあなたはそれが将来のを防ぐために必要はありませんあなたが拡張場合ので、いずれかの変更enum、その後、構築物はしまうすでに警告を生成します。

そのため、コンパイラは、すべてのベースをカバーしたが、カバーしていないと考えているように見えることに気付き、それは常に悪い兆候です。switch予想される形式に変更するために最小限の労力をかけることで、コンパイラに、あなたがしているように見えることが実際にあなたがしていることであり、それを知っていることを示します。

Clangは混乱しており、デフォルトのステートメントがあり、完全に素晴らしいプラクティスがあります。これは防御プログラミングとして知られており、優れたプログラミングプラクティスと見なされています（1）。デスクトッププログラミングではないかもしれませんが、ミッションクリティカルなシステムでよく使用されます。

防御的プログラミングの目的は、理論上は決して起こらない予期しないエラーをキャッチすることです。このような予期しないエラーは、必ずしもプログラマーが関数に誤った入力を与えたり、「悪意のあるハック」を行ったりするわけではありません。おそらく、変数の破損が原因である可能性があります。バッファオーバーフロー、スタックオーバーフロー、ランナウェイコード、および関数に関連しない同様のバグが原因です。また、組み込みシステムの場合、特に外部RAM回路を使用している場合、EMIにより変数が変更される可能性があります。

デフォルトのステートメント内に何を書くかについては...そこにたどりついてプログラムが大混乱になった疑いがある場合は、何らかのエラー処理が必要です。多くの場合、「予期しないが問題ではない」などのコメント付きの空のステートメントを追加するだけで、考えられない状況を考えたことを示すことができます。

（1）MISRA-C：2004 15.3。

より良い：

typedef enum {
    MaskValueUno,
    MaskValueDos,

    MaskValue_count
} testingMask;

void myFunction(testingMask theMask) {
    assert(theMask >= 0 && theMask<MaskValue_count);
    switch theMask {
        case MaskValueUno: {}// deal with it
        case MaskValueDos: {}// deal with it
    }
};

これは、列挙に項目を追加するときにエラーが発生しにくくなります。列挙値を符号なしにする場合、0以上のテストをスキップできます。このメソッドは、列挙値にギャップがない場合にのみ機能しますが、多くの場合はそうです。

しかし、ハックがやって来て、初期化されていないintを美しい関数に投げ込んだらどうなるでしょうか？

その後、Undefined Behaviorを取得しますdefaultが、意味がありません。これを改善するためにできることは何もありません。

もっとはっきりさせてください。誰かがintあなたの関数に初期化されていないものを渡す瞬間、それは未定義の振る舞いです。あなたの関数は停止問題を解決できますが、それは問題ではありません。UBです。UBが呼び出されたら、おそらくできることは何もありません。

デフォルトのステートメントは必ずしも役立つとは限りません。スイッチが列挙型の上にある場合、列挙型で定義されていない値は未定義の動作を実行することになります。

ご存知のとおり、コンパイラはそのスイッチを（デフォルトで）次のようにコンパイルできます。

if (theMask == MaskValueUno)
  // Execute something MaskValueUno code
else // theMask == MaskValueDos
  // Execute MaskValueDos code

未定義の動作をトリガーすると、戻ることはありません。

また、私default:はすべての場合に持っていることを好む。私はいつものようにパーティーに遅れていますが、...私が上で見なかった他の考え：

• 特定の警告（または、スローする場合はエラー-Werror）は-Wcovered-switch-default（から-Weverythingではなく-Wall）から来ています。道徳的な柔軟性により、特定の警告をオフにできる場合（つまり、-Wallまたはから一部を切り取る-Weverything）、投げる-Wno-covered-switch-default（または-Wno-error=covered-switch-default使用する場合）を検討-Werrorし、一般的-Wno-...に不快と思われる他の警告についても検討します。
• 以下のためにgcc（で、より汎用的な行動clang）、ご相談gccのマンページ-Wswitch、-Wswitch-enum、-Wswitch-defaultswitch文で列挙型の同様の状況にあるため（別の）行動を。

• 私はまた、この警告の概念が好きではなく、その言葉遣いも好きではありません。私には、警告からの言葉（「デフォルトラベル...すべての...値をカバー」）は、次のdefault:ようにケースが常に実行されることを示唆しています。

  switch (foo) {
    case 1:
      do_something(); 
      //note the lack of break (etc.) here!
    default:
      do_default();
  }

  最初に読んだとき、これはあなたが遭遇したと私が思ったものです-あなたのdefault:ケースはないbreak;か、return;または類似しているので、常に実行されます。この概念は、（私の耳にとって）他の乳母スタイルの（時として役立つが）解説に似ていますclang。の場合foo == 1、両方の機能が実行されます。上記のコードにはこの動作があります。つまり、後続のケースからコードを実行し続ける可能性がある場合にのみ、ブレークアウトに失敗します！ただし、これは問題ではないようです。

物足りなさの危険にさらされて、完全性のためのいくつかの他の考え：

• ただし、この動作は、他の言語またはコンパイラでの積極的な型チェックと（より）一貫していると思います。あなたが仮説として、何らかの調査がintこの関数に何かを渡すことを試みた場合、それは明示的にあなた自身の特定の型を消費することを意図しています、コンパイラは積極的な警告またはエラーでそのような状況であなたを等しく保護する必要があります。しかし、そうではありません！（つまり、少なくともタイプチェックgccをclang行わないように見えますが、enumiccありません）。型の安全性を取得していないため、上記のように値の安全性を取得できます。そうでない場合は、TFAで提案されているように、structタイプセーフを提供できるa または何かを検討してください。
• 別の回避策は、新しい「値」を作成することです enumなどMaskValueIllegal、およびそれをサポートしていないcaseあなたにswitch。それはdefault:（他の奇抜な価値に加えて）食べられるだろう

長生きする防御コーディング！

別の提案があります：
OPはint、enumが期待される場所に誰かが通過する場合から保護しようとしています。または、より多くの場合、誰かがより多くのケースで新しいヘッダーを使用して古いライブラリを新しいプログラムにリンクした場合です。

intケースを処理するようにスイッチを変更してみませんか？スイッチの値の前にキャストを追加すると、警告がなくなり、デフォルトが存在する理由についてのある程度のヒントも提供されます。

void myFunction(testingMask theMask) {
    int maskValue = int(theMask);
    switch(maskValue) {
        case MaskValueUno: {} // deal with it
        case MaskValueDos: {}// deal with it
        default: {} //deal with an unexpected or uninitialized value
    }
}

これは、可能な値のそれぞれをテストしたり、列挙値の範囲が整頓されていて、より簡単なテストが機能すると仮定したりするよりも、はるかに不快ではありません。これは、デフォルトが正確かつ美しく行うことを行うugい方法です。assert()