Clang / LLVM neden tüm numaralandırılmış durumların ele alındığı bir switch ifadesinde varsayılan kullanım konusunda beni uyarıyor?

Aşağıdaki enum ve switch deyimini göz önünde bulundurun:

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

Ben bir Objective-C programcısıyım, ancak bunu daha geniş bir kitleye C saf yazdım.

-Weverything olan Clang / LLVM 4.1, beni varsayılan satırda uyarır:

Tüm numaralandırma değerlerini kapsayan anahtardaki varsayılan etiket

Şimdi, bunun neden orada olduğunu görebiliyorum: mükemmel bir dünyada, tartışmaya giren tek değerler enumda theMaskolacaktı, bu nedenle varsayılan gerekmiyor. Peki ya bazı kesmek ortaya çıkar ve güzel işlevime başlatılmamış bir int atarsa? İşlevim kütüphanede bir düşüş olarak sağlanacak ve orada neler olabileceği üzerinde hiçbir kontrolüm yok. Kullanmak default, bunu ele almanın çok temiz bir yoludur.

LLVM tanrıları neden bu davranışı infernal cihazlarının değersiz görmektedir? Argümanı kontrol etmek için bundan önce bir if ifadesiyle mi başlamalıyım?

İşte ne sorun clang'ın raporlamasından ne de koruduğunuzdan muzdarip olan bir versiyonu:

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

Killian zaten clang'ın neden uyarı verdiğini açıkladı: enum'u uzattıysanız, muhtemelen istediğiniz şey olmayan varsayılan duruma düşersiniz. Yapılacak doğru şey, varsayılan davayı kaldırmak ve işlenmeyen koşullar için uyarılar almaktır .

Artık birisinin işlevinizi numaralandırma dışında bir değerle çağırabileceğinden endişe ediyorsunuz. Bu, işlevin ön koşulunu yerine getirememe gibi görünüyor: testingMasknumaralandırmadan bir değer beklediği belgelenmiştir ancak programcı başka bir şeyden geçmiştir. Bu yüzden kullanarak bir programcı hatası yapınassert() (ya NSCAssert()da Objective-C kullanıyormuşsunuz gibi). Programlayıcınız yanlış yaparsa, programlayıcının yanlış yaptığını açıklayan bir mesajla programınızın kilitlenmesini sağlayın.

Burada defaultetiket olması , beklediğiniz şey hakkında kafanızın karıştığının bir göstergesidir. Tüm olası enumdeğerleri açık bir şekilde tükettiğiniz için default, muhtemelen çalıştırılamaz ve gelecekteki değişikliklere karşı korunmalarına gerek yoktur, çünkü eğer genişletirseniz enum, o zaman yapı zaten bir uyarı verecektir .

Dolayısıyla, derleyici tüm üsleri kapladığınızı ancak henüz sahip olmadığınızı düşünüyor gibi göründüğünü fark eder ve bu her zaman kötü bir işarettir. switchBeklenen forma geçmek için en az çabayı göstererek, derleyiciye yaptığınız şeyin gerçekte ne yaptığınızı ve bunu bildiğinizi gösterirsiniz.

Clang'ın kafası karışık, varsayılan bir ifadeye sahip olan mükemmel bir uygulama var, savunma programlaması olarak bilinir ve iyi programlama uygulaması olarak kabul edilir (1). Belki de masaüstü programlamasında kullanılmasa da, görev kritik sistemlerde bolca kullanılır.

Savunma programlamasının amacı, teoride asla yaşanmayacak olan beklenmeyen hataları yakalamaktır. Bu tür beklenmeyen bir hata, fonksiyonun yanlış bir girdi veya hatta bir "kötü saldırı" vermesi için programcının mutlaka olması gerekmez. Daha büyük olasılıkla, bozuk bir değişken olabilir: arabellek taşması, yığın taşması, kaçak kodu ve işlevinizle ilgili olmayan benzeri hatalar buna neden olabilir. Gömülü sistemler söz konusu olduğunda değişkenler EMI nedeniyle, özellikle de harici RAM devreleri kullanıyorsanız değişebilir.

Varsayılan ifadenin içine ne yazdığına gelince ... eğer programın oraya gittiğinde haywire gittiğinden şüpheleniyorsan, bir çeşit hata işlemine ihtiyacın var. Pek çok durumda, muhtemelen beklenmedik bir durumda olduğunu düşündüğünüzü göstermek için "beklenmedik ama önemli değil" şeklinde bir yorum içeren boş bir ifade ekleyebilirsiniz.

(1) MISRA-C: 2004 15.3.

Hala daha iyi:

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

Bu, enuma öğe eklerken daha az hataya meyillidir. Enum değerlerinizi işaretsiz yaparsanız testi> = 0 için atlayabilirsiniz. Bu yöntem yalnızca enum değerlerinde boşluk yoksa, işe yarar, ancak bu genellikle böyle olur.

Peki ya bazı kesmek ortaya çıkar ve güzel işlevime başlatılmamış bir int atarsa?

O zaman Tanımsız Davranış elde edersiniz ve defaultanlamınız olmaz. Bunu daha iyi yapmak için yapabileceğin hiçbir şey yok.

Daha net olalım. Birisi intsizin fonksiyonunuza bir başlatılmamış geçerse , o Tanımsız Davranış. Göreviniz Halting Problemini çözebilir ve bunun önemi olmaz. Bu UB. UB çağrıldıktan sonra yapabileceğiniz hiçbir şey yoktur.

Varsayılan ifade mutlaka yardımcı olmaz. Anahtar bir numaralamanın üzerindeyse, numarada tanımlanmayan herhangi bir değer tanımsız davranışı gerçekleştirir.

Bildiğiniz kadarıyla, derleyici bu anahtarı (varsayılan olarak) aşağıdaki gibi derleyebilir:

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

Tanımsız davranışı tetikledikten sonra geri dönüş olmaz.

Ayrıca default:her durumda bir tane almayı tercih ederim . Her zamanki gibi partiye geç kaldım, ama ... yukarıda görmediğim başka düşünceler:

• Özel uyarı (ya da fırlatıldığında da hata -Werror) gelen -Wcovered-switch-default(gelen -Weverythingama olmayan -Wall) geliyor. Ahlaki esnekliğiniz, bazı uyarıları kapatmanıza izin veriyorsa (yani, bazı şeyleri -Wallveya bunlardan çıkarmayı-Weverything ), atmayı düşünün -Wno-covered-switch-default(veya -Wno-error=covered-switch-defaultkullanırken -Werror) ve genel -Wno-...olarak uygunsuz bulduğunuz diğer uyarılar için.
• İçin gcc(ve daha genel davranış clang), danışmak gcciçin manpage -Wswitch, -Wswitch-enum, -Wswitch-defaultswitch ifadeleri sayılan türde benzer durumlarda için (farklı) davranışının.

• Konseptdeki bu uyarıdan da hoşlanmıyorum ve ifadelerini de sevmiyorum; bana göre, uyarıdaki kelimeler ("varsayılan etiket ... tüm değerleri kapsar ... değerleri"), default:durumun her zaman yürütüleceğini, örneğin

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

  İlk okuduğumda, bununla karşılaştığınızı düşündüğüm şeydi - default:davanızın her zaman idam edileceği, çünkü hiçbir şey break;ya return;da benzeri bir şey yoktu . Bu kavram (kulağımla), diğerlerinden dağıttığı diğer dadı tarzı (bazen yararlı olsa da) yorumuna benzer clang. Eğer foo == 1iki fonksiyon da yerine getirilirse; Yukarıdaki kodunuzda bu davranış var. Yani, yalnızca sonraki vakalardan kod çalıştırmaya devam etmek istemeniz durumunda, ayrılma konusunda başarısız olun! Ancak bu, sizin probleminiz değil gibi görünüyor.

Pedantik olma riski altında olması için başka bazı düşünceler:

• Bununla birlikte, bu davranışın (daha fazla) diğer dillerde veya derleyicilerde agresif tür denetimi ile tutarlı olduğunu düşünüyorum. Eğer hipotez gibi bazı günahkar, varsa yok bir pas girişiminde intaçıkça kendi özgül türünü tüketmek niyetinde olan bu fonksiyonun, veya bir şey, sizin derleyici saldırgan bir uyarı veya hata ile bu durumda eşit derecede iyi korumak gerekir. AMA değil! (Yani, o en azından görünüyor gccve clangyapmayın enumtip denetimi, ama ben duymak iccyapar ). Eğer almıyorsanız beri tip -Emniyet, sen alabilir değeri yukarıda tartışıldığı gibi -Güvenlik. Aksi takdirde, TFA’da önerildiği gibi, structtip güvenliği sağlayabilecek bir şey veya bir şey düşünün .
• Başka bir geçici çözüm sizin de yeni bir "değer" oluşturarak olabilir enumgibi MaskValueIllegalve bu desteklemeyen caseGözlerinde farklı switch. Bu default:(başka bir tuhaf değere ek olarak) tarafından yemiş

Yaşasın savunma kodlaması!

İşte size alternatif bir öneri:
OP, bir kişinin enum'un beklendiği intyerde geçtiği davaya karşı korumaya çalışıyor . Veya daha büyük olasılıkla, birisinin daha fazla vaka içeren daha yeni bir başlık kullanarak eski bir kütüphaneyi daha yeni bir programla ilişkilendirdiği durumlarda.

intDavayı ele almak için neden anahtarı değiştirmiyorsunuz ? Anahtardaki değerin önüne bir döküm eklemek, uyarıyı ortadan kaldırır ve hatta varsayılanın neden olduğu hakkında bir ipucu sağlar.

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

Bunu , olası değerlerin her birinin test edilmesinden ya da enum değer aralığının iyi sıralandığı ve daha basit bir testin işe yaradığı varsayımıyla yapılmasından daha az sakıncalı buluyorum . Bu, varsayılanın tam ve güzelce yaptığı şeyi yapmanın çirkin bir yoludur.assert()