Dlaczego Clang / LLVM ostrzega mnie przed użyciem wartości domyślnej w instrukcji switch, w której uwzględniono wszystkie wyliczone przypadki?

Rozważ następującą instrukcję wyliczania i przełączania:

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
    }
};

Jestem programistą Objective-C, ale napisałem to w czystym C dla szerszej publiczności.

Clang / LLVM 4.1 z -Wszystko ostrzega mnie w domyślnej linii:

Domyślna etykieta w przełączniku, która obejmuje wszystkie wartości wyliczeń

Teraz rozumiem, dlaczego tak jest: w idealnym świecie jedynymi wartościami wprowadzanymi do argumentu theMaskbyłyby wyliczenie, więc żadne domyślne nie jest konieczne. Ale co jeśli jakiś hack pojawi się i wrzuci niezainicjowaną int do mojej pięknej funkcji? Moja funkcja zostanie udostępniona jako zrzut w bibliotece i nie mam kontroli nad tym, co może się tam znaleźć. Używanie defaultjest bardzo zgrabnym sposobem radzenia sobie z tym.

Dlaczego bogowie LLVM uważają to zachowanie za niegodne ich piekielnego urządzenia? Czy powinienem poprzedzać to instrukcją if, aby sprawdzić argument?

Oto wersja, która nie cierpi ani z powodu zgłaszania problemów, ani tej, przed którą się strzeżesz:

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

Killian wyjaśnił już, dlaczego brzęk emituje ostrzeżenie: jeśli rozszerzysz wyliczenie, wpadniesz w domyślny przypadek, który prawdopodobnie nie jest tym, czego chcesz. Właściwe jest usunięcie domyślnej skrzynki i otrzymanie ostrzeżeń o nieobsługiwanych warunkach.

Teraz obawiasz się, że ktoś może wywołać twoją funkcję z wartością spoza wyliczenia. To brzmi jak niespełnienie warunku wstępnego funkcji: udokumentowano, że oczekuje wartości z testingMaskwyliczenia, ale programista przeszedł coś innego. Zrób więc błąd programisty przy użyciu assert()(lub NSCAssert()jak powiedziałeś, że używasz Objective-C). Spraw, aby Twój program się zawiesił, wyświetlając komunikat wyjaśniający, że programista robi to źle, jeśli programista robi to źle.

Posiadanie defaulttutaj etykiety jest wskaźnikiem, że nie rozumiesz, czego się spodziewasz. Ponieważ wszystkie enumwartości zostały jawnie wyczerpane , defaultprawdopodobnie nie można ich wykonać i nie trzeba ich też chronić przed przyszłymi zmianami, ponieważ jeśli rozszerzysz enum, to konstrukcja wygeneruje już ostrzeżenie.

Tak więc kompilator zauważa, że ​​obejrzałeś wszystkie podstawy, ale wydaje się, że myślisz , że nie, i to zawsze jest zły znak. Podejmując minimalne wysiłki, aby zmienić switchoczekiwaną formę, demonstrujesz kompilatorowi, że to, co wydaje się robić, jest tym, co faktycznie robisz, i wiesz o tym.

Clang jest zdezorientowany, mając domyślne stwierdzenie, że istnieje doskonała praktyka, jest znany jako programowanie defensywne i jest uważany za dobrą praktykę programowania (1). Jest często używany w systemach o znaczeniu krytycznym, choć może nie w programowaniu na pulpicie.

Programowanie obronne ma na celu wychwycenie nieoczekiwanych błędów, które teoretycznie nigdy by się nie zdarzyły. Taki nieoczekiwany błąd niekoniecznie oznacza, że ​​programista podaje funkcji niepoprawne dane wejściowe, a nawet „zły hack”. Bardziej prawdopodobne jest, że może to być spowodowane uszkodzoną zmienną: przyczyną mogą być przepełnienia bufora, przepełnienie stosu, niekontrolowany kod i podobne błędy niezwiązane z funkcją. W przypadku systemów wbudowanych zmienne mogą się zmieniać z powodu zakłóceń elektromagnetycznych, szczególnie jeśli używasz zewnętrznych obwodów pamięci RAM.

Co do tego, co napiszę w domyślnej instrukcji ... jeśli podejrzewasz, że program zwariował, gdy tam trafiłeś, potrzebujesz jakiejś obsługi błędów. W wielu przypadkach prawdopodobnie możesz po prostu dodać puste zdanie z komentarzem: „nieoczekiwany, ale nie ma znaczenia” itp., Aby pokazać, że zastanowiłeś się nad nieoczekiwaną sytuacją.

(1) MISRA-C: 2004 15.3.

Jeszcze lepiej:

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
    }
};

Jest to mniej podatne na błędy podczas dodawania elementów do wyliczenia. Możesz pominąć test dla> = 0, jeśli twoje wartości wyliczone są niepodpisane. Ta metoda działa tylko wtedy, gdy nie ma luk w wartościach wyliczeniowych, ale często tak jest.

Ale co jeśli jakiś hack pojawi się i wrzuci niezainicjowaną int do mojej pięknej funkcji?

Wtedy otrzymasz niezdefiniowane zachowanie i swojedefault wola będzie bez znaczenia. Nic nie możesz zrobić, aby to poprawić.

Pozwól mi być bardziej jasne. Gdy tylko ktoś przejdzie intw twoją funkcję niezainicjalizowany , stanie się niezdefiniowanym. Twoja funkcja może rozwiązać problem zatrzymania i nie ma znaczenia. To jest UB. Po wywołaniu UB nie można nic zrobić.

Domyślna instrukcja niekoniecznie pomoże. Jeśli przełącznik znajduje się nad wyliczeniem, każda wartość, która nie jest zdefiniowana w wyliczeniu, spowoduje niezdefiniowane zachowanie.

Z tego co wiesz, kompilator może skompilować ten przełącznik (z ustawieniem domyślnym) jako:

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

Po uruchomieniu nieokreślonego zachowania nie ma już powrotu.

Ja też wolę mieć default:we wszystkich przypadkach. Jak zwykle spóźniam się na przyjęcie, ale ... kilka innych myśli, których nie widziałem powyżej:

• Szczególne ostrzeżenie (lub błąd, jeśli także rzucanie -Werror) pochodzi od -Wcovered-switch-default(z, -Weverythingale nie -Wall). Jeśli twoja moralna elastyczność pozwala ci wyłączyć niektóre ostrzeżenia (tj. Wyciąć niektóre rzeczy z -Walllub -Weverything), rozważ rzucanie -Wno-covered-switch-default(lub -Wno-error=covered-switch-defaultpodczas używania -Werror), i ogólnie -Wno-...dla innych ostrzeżeń, które uważasz za nieprzyjemne.
• Do gcc(i bardziej ogólne zachowanie w clang), skonsultować gccmanpage dla -Wswitch, -Wswitch-enum, -Wswitch-defaultdla (różnych) zachowanie w podobnych sytuacjach wymienionych typów w sprawozdaniu przełącznika.

• Nie podoba mi się też to ostrzeżenie w koncepcji i nie podoba mi się jego brzmienie; dla mnie słowa z ostrzeżenia („etykieta domyślna ... obejmuje wszystkie ... wartości”) sugerują, że default:sprawa będzie zawsze wykonywana, na przykład

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

  Przy pierwszym czytaniu myślałem, że na to wpadłeś - że twoja default:sprawa będzie zawsze wykonywana, ponieważ nie ma break;lub nie ma return;podobnego. Ta koncepcja jest podobna (do mojego ucha) do innych komentarzy w stylu niani (choć czasami pomocnych), z których wyłania się clang. Jeśli foo == 1obie funkcje zostaną wykonane; powyższy kod ma takie zachowanie. Tj. Nie przełamuj się tylko wtedy, gdy chcesz nadal wykonywać kod z kolejnych przypadków! Wydaje się to jednak nie być twoim problemem.

Ryzykując pedantyczne, kilka innych myśli o kompletności:

• Myślę jednak, że takie zachowanie jest (bardziej) spójne z agresywnym sprawdzaniem typów w innych językach lub kompilatorach. Jeżeli, jak to hipotezę, niektóre potępiony nie próbować przekazać intlub coś do tej funkcji, która jest wyraźnie zamierzający konsumować własny typ specyficzny, kompilator powinien zabezpieczyć się równie dobrze w tej sytuacji z agresywnym ostrzeżenia lub błędu. Ale tak nie jest! (To znaczy, wydaje się, że co najmniej gcci clangnie rób enumtypu sprawdzania, ale słyszę, że iccrobi ). Ponieważ nie otrzymujesz bezpieczeństwa typu , możesz uzyskać bezpieczeństwo wartości, jak omówiono powyżej. W przeciwnym razie, jak zasugerowano w TFA, zastanów się nad structczymś, co może zapewnić bezpieczeństwo typu.
• Innym obejściem może być tworzenie nowej „wartości” w twoim, na enumprzykład MaskValueIllegal, i nie wspieranie tego casew twoim switch. Zostałby zjedzony przez default:(oprócz każdej innej zwariowanej wartości)

Niech żyje kodowanie obronne!

Oto alternatywna sugestia:
OP stara się chronić przed przypadkiem, gdy ktoś przechodzi w miejscu, w intktórym spodziewany jest wyliczenie . Lub, bardziej prawdopodobne, gdy ktoś połączył starą bibliotekę z nowszym programem przy użyciu nowszego nagłówka z większą liczbą przypadków.

Dlaczego nie zmienić przełącznika do obsługi intskrzynki? Dodanie rzutowania przed wartością w przełączniku eliminuje ostrzeżenie, a nawet daje pewien podpowiedź, dlaczego istnieje wartość domyślna.

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
    }
}

Uważam, że jest to o wiele mniej budzące zastrzeżenia niż assert()testowanie każdej z możliwych wartości, a nawet przyjmowanie założenia, że ​​zakres wartości wyliczeniowych jest dobrze uporządkowany, dzięki czemu działa prostszy test. Jest to po prostu brzydki sposób robienia tego, co domyślne robi dokładnie i pięknie.