为什么Clang / LLVM在覆盖所有枚举情况的switch语句中警告我使用default？

考虑以下枚举和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将在枚举中，因此不需要默认值。但是，如果出现一些hack并将未初始化的int放入我的漂亮函数中怎么办？我的功能将作为库中的一部分提供，我无法控制其中的内容。使用default是处理此问题的一种非常简洁的方法。

为什么LLVM众神认为这种行为不符合他们的地狱装置？我应该在前面加上if语句来检查参数吗？

这是一个版本，既不受问题叮当的报告困扰，也不受您的防范：

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

Killian已经解释了clang发出警告的原因：如果扩展枚举，则会陷入默认情况，这可能不是您想要的。正确的做法是删除默认情况并获取未处理情况的警告。

现在，您担心有人会使用枚举之外的值来调用您的函数。听起来好像没有满足函数的先决条件：有记录表明期望testingMask枚举有一个值，但是程序员通过了其他操作。因此，请使用（或如您所说的使用Objective-C）使程序员出错。如果程序员做错了，则显示一条消息，说明程序员做错了，使您的程序崩溃。assert()NSCAssert()

在default这里贴上标签可以表明您对期望值感到困惑。由于您已enum明确用尽所有可能的值，因此default可能无法执行，并且也不需要它来防止将来的更改，因为如果扩展enum，则该构造将已经生成警告。

因此，编译器注意到您已经涵盖了所有基础，但似乎在想您没有，这始终是一个不好的信号。通过最小的努力将更switch改为期望的形式，您可以向编译器证明您似乎在做的就是您实际在做的事情，并且您知道这一点。

Clang感到困惑，有一个默认语句，这是一种很好的实践，它被称为防御性编程，被认为是良好的编程实践（1）。它在关键任务系统中被大量使用，尽管在桌面编程中可能不使用。

防御性编程的目的是捕获理论上永远不会发生的意外错误。这样的意外错误不一定是程序员为函数提供了不正确的输入，甚至是“恶意破解”。更有可能的原因是变量损坏：缓冲区溢出，堆栈溢出，代码失控以及与您的功能无关的类似错误可能是导致这种情况的原因。对于嵌入式系统，变量可能会因EMI而改变，尤其是在使用外部RAM电路的情况下。

至于在默认语句中写些什么……如果您怀疑程序一旦结束就已经麻烦了，那么您需要某种错误处理。在许多情况下，您可能只需要添加一个带有注释的空语句即可：“出乎意料，但无关紧要”等，以表明您已经考虑到了不太可能的情况。

（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的测试。此方法仅在枚举值之间没有空格的情况下才有效，但通常是这种情况。

但是，如果出现一些hack并将未初始化的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-default的（不同的）在switch语句中的枚举类型的类似情况的行为。

• 我也从概念上不喜欢这个警告，也不喜欢它的措辞。对我而言，警告中的字样（“默认标签...覆盖所有...值”）表明该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不进行enum类型检查，但我听说这样icc做了）。由于您没有获得类型安全性，因此可以得到如上所述的价值安全性。否则，按照TFA中的建议，考虑struct可以提供类型安全的或。
• 另一种解决方法可以创造你的新的“价值” enum等MaskValueIllegal，而不是支持了case你switch。这将被吃掉default:（除了任何其他古怪值）

防御编码万岁！

这里有一个替代建议：
在OP正试图在那里有人经过在防范的情况下int，其中一个枚举的预期。或者，更有可能的是，有人使用更多情况下的较新标头将旧库与较新程序链接在一起。

为什么不更改开关以处理这种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
    }
}

我觉得这多比少反感assert()每一个可能值的测试，甚至会假设范围枚举值是秩序井然，这样一个简单的测试工作。这只是默认值精确而精美地做的丑陋方式。