Чому Clang / LLVM попереджає мене про використання за замовчуванням у операторі комутатора, де охоплені всі перелічені випадки?

Розглянемо наступне твердження enum and 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, але це я написав у чистому С для широкої аудиторії.

Clang / LLVM 4.1 з -Weverything попереджає мене у рядку за замовчуванням:

Мітка за замовчуванням у перемикачі, яка охоплює всі значення перерахування

Тепер я можу розібратися, чому це саме так: в ідеальному світі єдині значення, що вводяться в аргумент, theMaskбули б у перерахунку, тому за замовчуванням не потрібно. Але що робити, якщо якийсь хак прийде разом і кине неініціалізований інт у мою прекрасну функцію? Моя функція буде забезпечуватися як падіння бібліотеки, і я не маю ніякого контролю над тим, що могло б туди потрапити. Використання default- це дуже акуратний спосіб вирішення цього питання.

Чому боги LLVM вважають цю поведінку недостойною свого пекельного пристрою? Чи повинен я передувати цьому твердженням if, щоб перевірити аргумент?

Ось версія, яка не страждає ні від звітності про проблемний Кланг, ні від тієї, яку ви захищаєте:

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

Кілліан уже пояснив, чому Кланг надсилає попередження: якщо ви продовжите перерахунок, ви потрапите в випадок за замовчуванням, який, ймовірно, не є тим, що ви хочете. Правильне, що потрібно зробити, - це видалити корпус за замовчуванням і отримати попередження про незроблені умови.

Тепер ви стурбовані тим, що хтось може викликати вашу функцію зі значенням, яке знаходиться поза перерахуванням. Це звучить як невиконання обов'язкової функції функції: документально очікувати значення від testingMaskперерахування, але програміст передав щось інше. Тому зробіть помилку програміста, використовуючи assert()(або, NSCAssert()як ви сказали, ви використовуєте Objective-C). Зробіть збиток програми повідомленням, в якому пояснюється, що програміст робить це неправильно, якщо програміст робить це неправильно.

Наявність defaultтут етикетки - це показник того, що ви плутаєтесь у тому, що очікуєте. Оскільки ви enumявно вичерпали всі можливі значення, defaultможливо, його неможливо виконати, і вам це також не потрібно для захисту від майбутніх змін, тому що якби ви розширили enum, конструкція вже генерує попередження.

Отже, компілятор помічає, що ви покрили всі бази, але, здається, думаєте, що цього не зробили, і це завжди поганий знак. Доклавши мінімум зусиль, щоб змінити switchформу на очікувану, ви демонструєте компілятору, що те, що, здається, ви робите, це те, що ви насправді робите, і ви це знаєте.

Кланг плутається, маючи твердження за замовчуванням, існує прекрасна практика, воно відоме як оборонне програмування і вважається хорошою практикою програмування (1). Він використовується досить багато в критичних для місії системах, хоча, можливо, і не в настільному програмуванні.

Мета оборонного програмування - зловити несподівані помилки, які теоретично ніколи не трапляться. Таку несподівану помилку не обов'язково програміст дає функцію неправильним введенням або навіть "злим злому". Швидше за все, це може бути викликано пошкодженою змінною: переповнення буфера, переповнення стека, відбійний код та подібні помилки, не пов'язані з вашою функцією, можуть спричинити це. І у випадку вбудованих систем, змінні можуть змінитися через 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, якщо ви зробите значення без перерахунку. Цей метод працює лише в тому випадку, якщо у вас немає прогалин у ваших значеннях перерахування, але це часто буває.

Але що робити, якщо якийсь хак прийде разом і кине неініціалізований інт у мою прекрасну функцію?

Тоді ви отримуєте не визначену поведінку , і ваша defaultбуде безглуздою. Ви нічого не можете зробити, щоб зробити це краще.

Дозвольте мені бути більш зрозумілим. Миттєво, коли хтось переходить неініціалізований intу вашу функцію, це Невизначена поведінка. Ваша функція може вирішити проблему зупинки, і це не має значення. Це UB. Щойно ви не зможете зробити, коли викликали UB.

Заява за замовчуванням не обов'язково допоможе. Якщо перемикач знаходиться над перерахунком, будь-яке значення, яке не визначено в enum, в кінцевому підсумку виконує невизначене поведінку.

Усім, що ви знаєте, компілятор може компілювати цей комутатор (за замовчуванням) як:

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для (різні) поведінки в подібних ситуаціях , перерахованих типів в операторах перемикання.

• Мені також не подобається це попередження в концепції, і мені не подобається його формулювання; для мене слова з попередження ("мітка за замовчуванням ... охоплює всі ... значення") говорять про те, що 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:(крім будь-якого іншого дурного значення)

Хай живе захисне кодування!

Ось альтернативну пропозицію:
ВП намагається захиститися від випадку , коли хто - то переходить в 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()тестування кожного з можливих значень або навіть зробити припущення про те, що діапазон перераховуються значень стрункою , так що більш простий тест працює. Це просто потворний спосіб робити те, що за замовчуванням робить точно і красиво.