Tanımlanmamış davranışa sahip dalların erişilemez olduğu ve ölü kod olarak optimize edilebileceği varsayılabilir mi?

Şu ifadeyi düşünün:

*((char*)NULL) = 0; //undefined behavior

Açıkça tanımlanmamış davranışa neden olur. Belirli bir programda böyle bir ifadenin varlığı, tüm programın tanımsız olduğu veya davranışın yalnızca kontrol akışı bu ifadeye ulaştığında tanımsız hale geldiği anlamına mı gelir?

Kullanıcının numarayı hiç girmemesi durumunda aşağıdaki program iyi tanımlanmış olur 3mu?

while (true) {
 int num = ReadNumberFromConsole();
 if (num == 3)
  *((char*)NULL) = 0; //undefined behavior
}

Yoksa kullanıcı ne girerse girsin, tamamen tanımlanmamış bir davranış mı?

Ayrıca, derleyici tanımsız davranışın çalışma zamanında asla çalıştırılmayacağını varsayabilir mi? Bu, zamanda geriye doğru akıl yürütmeye izin verir:

int num = ReadNumberFromConsole();

if (num == 3) {
 PrintToConsole(num);
 *((char*)NULL) = 0; //undefined behavior
}

Burada derleyici num == 3, her zaman tanımsız davranışı çağıracağımızı düşünebilir . Bu nedenle bu durum imkansız olmalı ve numaranın basılmasına gerek yoktur. Tüm ififade optimize edilebilir. Standarda göre bu tür geriye doğru akıl yürütmeye izin veriliyor mu?

Belirli bir programda böyle bir ifadenin varlığı, tüm programın tanımsız olduğu veya davranışın yalnızca kontrol akışı bu ifadeye ulaştığında tanımsız hale geldiği anlamına mı gelir?

Hiçbiri. İlk koşul çok güçlü ve ikincisi çok zayıf.

Nesne erişimi bazen sıralıdır, ancak standart, programın zaman dışındaki davranışını tanımlar. Danvil zaten alıntı yaptı:

Böyle bir yürütme tanımlanmamış bir işlem içeriyorsa, bu Uluslararası Standart, bu programın bu girdi ile çalıştırılmasına ilişkin hiçbir gereklilik getirmez (ilk tanımsız işlemden önceki işlemlerle ilgili olarak bile)

Bu şu şekilde yorumlanabilir:

Programın yürütülmesi tanımlanmamış bir davranışa neden olursa, tüm programın tanımsız davranışı vardır.

Yani, UB ile ulaşılamaz bir ifade programa UB vermez. (Girişlerin değerleri nedeniyle) asla ulaşılmayan ulaşılabilir bir ifade, programa UB vermez. Bu yüzden ilk kondisyonunuz çok güçlü.

Şimdi, derleyici genel olarak UB'nin ne olduğunu söyleyemez. Dolayısıyla, optimize edicinin, davranışlarının tanımlanması durumunda yeniden sıralanabilecek potansiyel UB içeren ifadeleri yeniden sıralayabilmesi için, UB'nin "zamanda geri dönmesine" ve önceki sıra noktasından önce (veya C) yanlış gitmesine izin vermek gerekir. ++ 11 terminolojisi, UB'nin UB şeyinden önce sıralanan şeyleri etkilemesi için). Bu nedenle ikinci durumunuz çok zayıf.

Bunun başlıca bir örneği, optimize edicinin katı örtüşme işlemine dayandığı zamandır. Katı örtüşme kurallarının tüm amacı, derleyicinin, söz konusu işaretçilerin aynı belleğe takma ad vermesi mümkün olsaydı, geçerli bir şekilde yeniden sıralanamayacak işlemleri yeniden düzenlemesine izin vermektir. Dolayısıyla, yasadışı olarak örtüşme işaretçileri kullanırsanız ve UB oluşursa, UB ifadesinden "önceki" bir ifadeyi kolayca etkileyebilir. Soyut makine söz konusu olduğunda, UB ifadesi henüz çalıştırılmadı. Asıl nesne kodu söz konusu olduğunda, kısmen veya tamamen yürütülmüştür. Ancak standart, optimize edicinin ifadeleri yeniden düzenlemesinin ne anlama geldiğine veya bunun UB için sonuçlarının ne olduğuna dair ayrıntılara girmeye çalışmaz. Sadece uygulama ruhsatının istediği anda ters gitmesini sağlar.

Bunu "UB'nin bir zaman makinesi var" olarak düşünebilirsiniz.

Özellikle örneklerinize cevap vermek için:

• Davranış, yalnızca 3 okunursa tanımsızdır.
• Temel bir blok tanımsız olduğu kesin olan bir işlem içeriyorsa, derleyiciler kodu ölü olarak ortadan kaldırabilir ve yapar. Temel bir blok olmayan ancak tüm dalların UB'ye yol açtığı durumlarda izin verilir (ve tahmin ediyorum). Bu örnek, bir PrintToConsole(3)şekilde geri döneceğinden emin olmadıkça bir aday değildir . Bir istisna falan atabilir.

İkincinize benzer bir örnek -fdelete-null-pointer-checks, şu şekilde kod alabilen gcc seçeneğidir (bu özel örneği kontrol etmedim, genel fikri açıklayıcı olarak düşünün):

void foo(int *p) {
    if (p) *p = 3;
    std::cout << *p << '\n';
}

ve şu şekilde değiştirin:

*p = 3;
std::cout << "3\n";

Neden? Çünkü pnull ise , o zaman kodun yine de UB'si vardır, bu yüzden derleyici onun boş olmadığını varsayabilir ve buna göre optimize edebilir. Linux çekirdeği bunun üzerine açıldı ( https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1897 ) esasen bir boş göstericiye başvurunun kaldırılmasının gerekmediği bir modda çalıştığı için UB olması durumunda, çekirdeğin işleyebileceği tanımlanmış bir donanım istisnasıyla sonuçlanması beklenir. Optimizasyon etkinleştirildiğinde, gcc, -fno-delete-null-pointer-checksstandartların ötesinde garantiyi sağlamak için 'nin kullanılmasını gerektirir .

Not: "Tanımlanmamış davranış ne zaman ortaya çıkar?" Sorusunun pratik yanıtı. "gün için ayrılmayı planladığınızdan 10 dakika önce".

1.9 / 4'teki standart durumlar

[Not: Bu Uluslararası Standart, tanımlanmamış davranışlar içeren programların davranışına herhangi bir gereklilik getirmez. - son not]

İlginç olan nokta muhtemelen "içerme" nin ne anlama geldiğidir. 1.9 / 5'te biraz sonra şunu belirtir:

Bununla birlikte, bu tür bir yürütme tanımlanmamış bir işlem içeriyorsa, bu Uluslararası Standart, bu programı bu girdi ile yürüten uygulamaya herhangi bir gereklilik getirmez (ilk tanımsız işlemden önceki işlemlerle ilgili olarak bile)

Burada özellikle "bu girişle ... yürütme" den bahsediyor. Bunu şu anda yürütülmeyen olası bir daldaki tanımsız davranışın mevcut yürütme dalını etkilemediği şeklinde yorumluyorum.

Ancak farklı bir sorun, kod üretimi sırasında tanımlanmamış davranışa dayalı varsayımlardır. Bununla ilgili daha fazla ayrıntı için Steve Jessop'un cevabına bakın.

Öğretici bir örnek

int foo(int x)
{
    int a;
    if (x)
        return a;
    return 0;
}

Hem mevcut GCC hem de mevcut Clang, bunu (x86'da) optimize edecek

xorl %eax,%eax
ret

onlar çünkü anlamak o xzaman sıfır olduğu içinde UB gelen if (x)denetim yolu. GCC size başlatılmamış değer kullanımı uyarısı bile vermez! (çünkü yukarıdaki mantığı uygulayan geçiş, başlatılmamış değer uyarıları oluşturan geçişten önce çalışır)

Mevcut C ++ çalışma taslağı 1.9.4'te şunu söylüyor:

Bu Uluslararası Standart, tanımlanmamış davranış içeren programların davranışına herhangi bir gereklilik getirmez.

Buna dayanarak, herhangi bir yürütme yolunda tanımsız davranış içeren bir programın, her çalıştırıldığında her şeyi yapabileceğini söyleyebilirim.

Tanımlanmamış davranışlar ve derleyicilerin genellikle yaptıkları hakkında gerçekten iyi iki makale var:

• C ve C ++ 'da Tanımsız Davranış Rehberi
• Her C Programcısının Tanımsız Davranış Hakkında Bilmesi Gerekenler

"Davranış" kelimesi, bir şeyin yapıldığı anlamına gelir . Asla yürütülmeyen bir durum "davranış" değildir.

Bir örnek:

*ptr = 0;

Bu tanımlanmamış davranış mı? ptr == nullptrProgramın yürütülmesi sırasında en az bir kez % 100 emin olduğumuzu varsayalım . Cevap evet olmalıdır.

Peki buna ne dersin?

 if (ptr) *ptr = 0;

Bu tanımsız mı? ( ptr == nullptrEn az bir kez hatırla ?) Umarım hayır, aksi takdirde hiçbir yararlı program yazamazsın.

Bu cevabın verilmesinde hiçbir Srandardlı zarar görmedi.

Tanımlanmamış davranış, program daha sonra ne olursa olsun tanımsız davranışa neden olduğunda ortaya çıkar. Ancak aşağıdaki örneği verdiniz.

int num = ReadNumberFromConsole();

if (num == 3) {
 PrintToConsole(num);
 *((char*)NULL) = 0; //undefined behavior
}

Derleyici tanımını bilmediği sürece koşulluyu PrintToConsolekaldıramaz if (num == 3). LongAndCamelCaseStdio.hAşağıdaki beyanı ile sistem başlığınız olduğunu varsayalım PrintToConsole.

void PrintToConsole(int);

Pek yardımcı olacak bir şey yok, tamam. Şimdi, bu işlevin gerçek tanımını kontrol ederek satıcının ne kadar kötü (veya belki de o kadar kötü olmayan, tanımlanmamış davranış daha kötü olabilirdi) görelim.

int printf(const char *, ...);
void exit(int);

void PrintToConsole(int num) {
    printf("%d\n", num);
    exit(0);
}

Derleyici aslında derleyicinin ne yaptığını bilmediği herhangi bir keyfi işlevin çıkabileceğini veya bir istisna atabileceğini varsaymalıdır (C ++ durumunda). *((char*)NULL) = 0;Çağrıdan sonra yürütme devam etmeyeceği için bunun yürütülmeyeceğini fark PrintToConsoleedebilirsiniz.

Tanımlanmamış davranış, PrintToConsolegerçekte geri döndüğünde dikkat çeker. Derleyici bunun olmamasını bekler (çünkü bu, programın ne olursa olsun tanımsız davranışı yürütmesine neden olur), bu nedenle her şey olabilir.

Ancak, başka bir şey düşünelim. Diyelim ki boş kontrol yapıyoruz ve değişkeni sıfır kontrolünden sonra kullanıyoruz.

int putchar(int);

const char *warning;

void lol_null_check(const char *pointer) {
    if (!pointer) {
        warning = "pointer is null";
    }
    putchar(*pointer);
}

Bu durumda, lol_null_checkNULL olmayan bir işaretçi gerektirdiğini fark etmek kolaydır . Global uçucu olmayan warningdeğişkene atama , programdan çıkabilecek veya herhangi bir istisna oluşturabilecek bir şey değildir. pointerSihirli (eğer olursa, o tanımsız bir davranış) işlevi ortasında değerini değiştirmez, böylece de uçucu değildir. Çağırma lol_null_check(NULL), değişkenin atanmamasına neden olabilecek tanımsız davranışa neden olur (çünkü bu noktada, programın tanımsız davranışı yürüttüğü bilinmektedir).

Ancak, tanımlanmamış davranış, programın her şeyi yapabileceği anlamına gelir. Bu nedenle, hiçbir şey tanımlanmamış davranışın zamanda geriye gitmesini ve programınızın ilk int main()yürütme satırından önce çökmesini engellemez . Tanımlanmamış bir davranış, mantıklı olması gerekmiyor. 3 yazdıktan sonra da çökebilir, ancak tanımlanmamış davranış zamanda geri dönecek ve siz 3 yazmadan önce çökecektir. Ve kim bilir, belki de tanımlanmamış davranış sistem RAM'inizin üzerine yazacak ve sisteminizin 2 hafta sonra çökmesine neden olacaktır, tanımsız programınız çalışmıyorken.

Program tanımlanmamış davranışı çağıran bir ifadeye ulaşırsa, programın herhangi bir çıktısına / davranışına herhangi bir gereksinim getirilmez; tanımsız davranış çağrıldığında "önce" veya "sonra" gerçekleşmeleri önemli değildir.

Her üç kod parçacığı hakkındaki mantığınız doğru. Özellikle, bir derleyici, tanımlanmamış davranışları koşulsuz __builtin_unreachable()olarak GCC'nin davrandığı şekilde çağıran herhangi bir ifadeyi , ifadenin erişilemez olduğuna (ve dolayısıyla koşulsuz olarak ona giden tüm kod yollarının da erişilemez olduğuna) dair bir optimizasyon ipucu olarak ele alabilir . Diğer benzer optimizasyonlar elbette mümkündür.

Pek çok şey için pek çok standart, IETF RFC 2119'da tanımlanana benzer bir terminoloji kullanarak (bu belgedeki tanımlara mutlaka atıfta bulunulmasa da) uygulamaların YAPMASI GEREKEN veya YAPMAMASI GEREKEN şeyleri açıklamak için çok çaba harcar . Çoğu durumda, uygulamaların yararsız veya pratik olmayacakları durumlar dışında yapması gereken şeylerin açıklamaları, tüm uyumlu uygulamaların uyması gereken gereksinimlerden daha önemlidir .

Ne yazık ki, C ve C ++ Standartları,% 100 gerekli olmasa da, ters davranışları belgelemeyen kaliteli uygulamalardan beklenilmesi gereken şeylerin tanımlarından kaçınma eğilimindedir. Uygulamaların bir şeyler yapması gerektiğine dair bir öneri, belirli bir uygulamada, olmayanların daha düşük olmadığını ve hangi davranışların kullanışlı veya pratik olacağının, pratik olmayan ve yararsız olacağının genellikle açık olduğu durumlarda, belirli bir uygulamada, Standardın bu tür yargılara müdahale etmesine çok az ihtiyaç duyulmaktadır.

Akıllı bir derleyici, Kodun kaçınılmaz olarak Tanımsız Davranışa neden olacak girdileri aldığı, ancak "zeki" ve "aptalca" zıt anlamlı olmayanlar dışında hiçbir etkisi olmayan herhangi bir kodu ortadan kaldırırken, Standard'a uyabilir. Standardın yazarlarının, belirli bir durumda yararlı bir şekilde davranmanın yararsız ve pratik olmayacağı bazı türden uygulamaların olabileceğine karar vermiş olması, bu tür davranışların başkaları için pratik ve yararlı olarak kabul edilip edilmeyeceği konusunda herhangi bir yargıya işaret etmez. Bir uygulama, bir "ölü dallı" budama fırsatının kaybının ötesinde hiçbir maliyet olmadan davranışsal bir garantiyi destekleyebiliyorsa, bu garantiden elde edilebilecek hemen hemen her değer kullanıcı kodu, bunu sağlama maliyetini aşacaktır. Ölü dalların ortadan kaldırılması, yapılmayacağı durumlarda iyi olabilir.Belirli bir durum kullanıcı kodu neredeyse olası davranışları ele olabilirdi eğer, ancak diğer ölü şube eleme daha herhangi bir çaba kullanıcı kodu UB olasılıkla DBE ulaşılan değeri aşacak önlemek için harcamak zorunda kalacaktı.