C ++ 'tanımsız davranış' (UB) ve C # veya Java gibi diğer diller neden yok?

Bu Yığın Taşması yayını , C / C ++ dil belirtiminin 'tanımsız davranış' olarak ilan ettiği durumların oldukça kapsamlı bir listesini listeler. Ancak, neden C # veya Java gibi diğer modern dillerin 'tanımsız davranış' kavramına sahip olmadığını anlamak istiyorum. Derleyici tasarımcı tüm olası senaryoları (C # ve Java) kontrol edebilir mi, yoksa (C ve C ++) kontrol edebilir mi?

Tanımlanmamış davranış, yalnızca geçmişe bakıldığında çok kötü bir fikir olarak kabul edilen şeylerden biridir.

İlk derleyiciler büyük başarılar elde etti ve alternatif - makine dili ya da meclis dili programlamasına nazaran gelişmeleri memnuniyetle karşıladı. Bununla ilgili sorunlar iyi biliniyordu ve üst düzey diller bilinen sorunları çözmek için özel olarak icat edildi. (O zamanki coşku o kadar büyüktü ki, HLL'ler “programlamanın sonu” olarak selamlanan somtimlerdi - sanki bundan sonra sadece istediklerimizi önemsiz bir şekilde yazmak zorunda kalacağız ve derleyici tüm gerçek işleri yapacaktı.)

Daha yeni bir yaklaşımla ortaya çıkan yeni sorunları fark edemedik. Kodun çalıştığı gerçek makineden uzak olmak, sessizce, yapmasını beklediğimiz şeyi yapmayan şeylerin daha fazla olabileceği anlamına gelir. Örneğin, bir değişken tahsis etmek tipik olarak başlangıç ​​değerini tanımsız bırakır; bu bir problem olarak görülmedi, çünkü eğer bir değer tutmak istemeseydiniz bir değişken tahsis edemezdiniz, değil mi? Profesyonel programcıların başlangıç ​​değerini vermeyi unutmamalarını beklemek elbette çok fazla değildi, değil mi?

Daha güçlü kodlama sistemleri ve daha güçlü programlama sistemleriyle mümkün olan daha karmaşık yapılarla, evet, pek çok programcının zaman zaman bu denemeleri gerçekten yerine getireceği ve sonuçta tanımlanamayan davranışların büyük bir sorun haline geldiği ortaya çıktı. Bugün bile, güvenlik sızıntılarının küçüğünden korkunçlara kaçması, bir biçimde veya bir diğerinde tanımsız davranışların sonucudur. (Bunun nedeni, genellikle tanımsız davranışın aslında hesaplamada bir sonraki daha düşük seviyedeki şeyler tarafından çok tanımlanmış olmasıdır ve bu seviyeyi anlayan saldırganlar, bir program yapmak için bu kıkırdama odasını yalnızca istenmeyen şeyleri değil, tam olarak yapılan şeyleri kullanabilir. onlar niyetinde.)

Bunu fark ettiğimizden beri, tanımsız davranışı yüksek seviyeli dillerden kovma konusunda genel bir itici güç vardı ve Java bu konuda özellikle kapsamlıydı (ki zaten kendi tasarımlı sanal makinesinde çalışacak şekilde tasarlandığından beri nispeten kolaydı). C gibi daha eski diller, varolan büyük miktarda kodla uyumluluğunu yitirmeden kolayca bu şekilde yeniden yapılandırılamaz.

Düzenleme: Belirtildiği gibi, verimlilik başka bir nedendir. Tanımlanmamış davranış, derleyici yazarların, hedef mimariden faydalanma konusunda çok fazla çaba harcadığı anlamına gelir; Bu, dünkü güçlendirilmiş makinelerde, programcı maaşının genellikle yazılım geliştirme için bir darboğaz olması durumunda, bugün olduğundan daha önemliydi.

Temel olarak, Java ve benzer dil tasarımcılarının dillerinde tanımsız davranış istememeleri nedeniyle. Bu bir takas oldu - tanımsız davranışa izin vermek performansı arttırma potansiyeline sahip, ancak dil tasarımcıları güvenlik ve öngörülebilirliği daha yüksek önceliklendirdi.

Örneğin, C'de bir dizi tahsis ederseniz, veriler tanımsızdır. Java'da, tüm baytların 0 (veya başka bir belirli değer) olarak başlatılması gerekir. Bu, çalışma zamanının dizi üzerinde geçmesi gerektiği (C (n) işlemi) anlamına gelirken, C anında tahsisat yapabilir. C bu tür işlemler için her zaman daha hızlı olacaktır.

Diziyi kullanan kod okumadan önce onu yerleştirecekse, bu temelde Java için harcanan çabadır. Ancak, ilk önce kodun okunması durumunda, Java’da öngörülebilir sonuçlar alırsınız ancak C’de öngörülemeyen sonuçlar elde edersiniz.

Tanımsız davranış, derleyiciye belirli sınırlarda veya başka koşullarda tuhaf veya beklenmedik (veya normal) bir şey yapma enlemini vererek önemli optimizasyon sağlar.

Bkz http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Başlatılmamış bir değişkenin kullanımı: Bu genellikle C programlarındaki sorunların kaynağı olarak bilinir ve bunları yakalamak için birçok araç vardır: derleyici uyarılarından statik ve dinamik analizörlere kadar. Bu, (Java'nın yaptığı gibi) kapsam dahilinde tüm değişkenlerin sıfır olarak başlatılmasını gerektirmeyerek performansı artırır. Çoğu skaler değişken için bu, fazla ek yüke neden olur, ancak yığın dizileri ve malloc'd belleği, özellikle de depolama genellikle tamamen üzerine yazıldığından, oldukça pahalı olabilecek bir depolama belleğine neden olur.

İşaretli tamsayı taşması: 'int' türündeki (örneğin) aritmetik taşarsa, sonuç tanımlanmaz. Bir örnek "INT_MAX + 1" in INT_MIN olması garanti edilmez. Bu davranış, bazı kodlar için önemli olan belirli optimizasyon sınıflarını etkinleştirir. Örneğin, INT_MAX + 1'in tanımsız olduğunu bilmek "X + 1> X" in "true" olarak optimize edilmesini sağlar. Çarpmayı bilmek "taşamaz" dır (çünkü bunu yapmak tanımsızdır), "X * 2/2" nin "X" e optimize edilmesini sağlar. Bunlar önemsiz gibi görünse de, bu tür şeyler genellikle iç içe ve makro genişleme ile ortaya çıkar. Bunun izin verdiği daha önemli bir optimizasyon, "<=" gibi döngüler içindir:

for (i = 0; i <= N; ++i) { ... }

Bu döngüde, derleyici, "i" nin taşma üzerinde tanımsız olması durumunda döngünün tam olarak N + 1 kez tekrarlanacağını varsayabilir, bu da geniş bir döngü optimizasyonunun başlamasını sağlar. Diğer taraftan, değişken tanımlanmışsa taşma üzerine sarılırsa, derleyici, döngünün muhtemelen sonsuz olduğunu varsaymalıdır (N, INT_MAX ise) - bu önemli döngü optimizasyonlarını devre dışı bırakır. Bu özellikle 64-bit platformları etkiler çünkü kodun çoğu indüksiyon değişkenleri olarak "int" kullanır.

C'nin ilk günlerinde, çok fazla kaos vardı. Farklı derleyiciler diline farklı davrandılar. Dil için bir spesifikasyon yazmaya ilgi olduğunda, bu şartnamenin programcıların derleyicileri ile güvendikleri C ile oldukça geriye dönük olması gerekir. Ancak, bu ayrıntıların bazıları taşınabilir değildir ve genel olarak anlamsızdır, örneğin belirli bir endianess veya veri düzenini varsaymak gibi. Bu nedenle C standardı, tanımlanmamış veya uygulama tarafından belirlenmiş davranış olarak birçok detayı saklar; bu, derleyici yazarlarına çok fazla esneklik bırakır. C ++ C üzerine kuruludur ve aynı zamanda tanımsız davranış sergiler.

Java, C ++ 'dan daha güvenli ve daha basit bir dil olmaya çalıştı. Java, dil semantiğini kapsamlı bir sanal makine açısından tanımlar. Bu, tanımlanmamış davranış için çok az yer bırakır, diğer yandan bir Java uygulamasının yapmasını zorlaştırmak için gereken gereksinimleri yapar (örneğin, bu referans atamaları atomik olmalı veya tam sayıların nasıl çalışması gerekir). Java'nın potansiyel olarak güvenli olmayan işlemleri desteklediği yerlerde, bunlar çalışma zamanında genellikle sanal makine tarafından kontrol edilir (örneğin, bazı yayınlar).

JVM ve .NET dilleri kolaylaşıyor:

1. Doğrudan donanımla çalışmak zorunda değiller.
2. Yalnızca modern masaüstü ve sunucu sistemleriyle veya makul şekilde benzer cihazlarla veya en azından onlar için tasarlanmış cihazlarla çalışmak zorundadırlar.
3. Tüm bellekler için çöp toplama ve zorla başlatma işlemlerini uygulayarak göstergenin güvenliğini sağlayabilirler.
4. Tek bir tanımlayıcı uygulamayı da sağlayan tek bir oyuncu tarafından belirlendiler.
5. Performans üzerinden güvenliği seçiyorlar.

Seçimler için iyi noktalar olsa da:

1. Sistem programlama tamamen farklı bir programdır ve bunun yerine uygulama programlaması için ödünsüz bir şekilde optimize edilmesi makul olur.
2. Kuşkusuz, her zaman daha az egzotik donanım var, ancak küçük gömülü sistemler burada kalıyor.
3. GC, fungus olmayan kaynaklar için uygun değildir ve iyi performans için çok daha fazla yer kaplar. Ve çoğu (ancak hemen hemen hepsi değil) zorunlu başlatmalar en iyi duruma getirilebilir.
4. Daha fazla rekabet avantajı var, ancak komiteler uzlaşma demek.
5. Tüm bu sınırlarla kontroller yapmak en uzağa optimize edilebilir olsa bile, kadar ekleyin. Null işaretçi kontrolleri çoğunlukla sanal adres alanı sayesinde sıfır genel gider için erişim yakalanarak gerçekleştirilebilir, ancak optimizasyon hala engellenmiştir.

Kaçış kapakları temin edildiğinde, bunlar tam gelişmiş tanımsız davranışı tekrar devreye sokarlar. Ancak, en azından, sadece çok kısa bir genişlikte kullanılırlar, bu nedenle manuel olarak doğrulanması daha kolaydır.

Java ve C #, en azından geliştirilmelerinin başında, hakim bir satıcı tarafından tanımlanır. (Sırasıyla Sun ve Microsoft). C ve C ++ farklıdır; en başından beri çok sayıda rakip uygulamaları vardı. C özellikle egzotik donanım platformlarında da çalıştı. Sonuç olarak, uygulamalar arasında farklılıklar vardı. C ve C ++ 'yı standart hale getiren ISO komiteleri büyük bir ortak payda üzerinde anlaşabilir, ancak uygulamaların uygulama için odadan ayrılan standartları değiştirdiği kenarlarda.

Bu aynı zamanda, bir davranışı seçmek, başka bir seçime eğilimli donanım mimarileri için pahalı olabileceğinden - endianness açık bir seçimdir.

Asıl sebep, bir yandan C ve C ++ ile diğer yandan Java ve C # (sadece birkaç örnek için) arasındaki niyet açısından temel bir farktan kaynaklanıyor. Tarihsel nedenlerden dolayı, buradaki tartışmaların çoğu C ++ 'dan ziyade C hakkında konuşur, fakat (muhtemelen zaten bildiğiniz gibi) C ++ C'nin oldukça doğrudan bir soyundandır, bu yüzden C hakkında söyledikleri eşit olarak C ++' a uygulanır.

Büyük ölçüde unutulmuş olmalarına rağmen (ve varlıkları bazen reddedilmiş olsalar da), UNIX'in ilk sürümleri assembly dilinde yazılmıştı. (Yalnızca değilse) C'nin asıl amacının çoğu, montaj dilinden daha yüksek bir dile kadar UNIX bağlantı noktasıydı. Niyetin bir kısmı, işletim sisteminde mümkün olan en yüksek düzeyde bir dilde yazmaktı - ya da diğer yönden bakmak, derleme dilinde yazılması gereken miktarı en aza indirmekti.

Bunu gerçekleştirmek için, C'nin donanıma derleme diliyle neredeyse aynı düzeyde erişim sağlaması gerekiyordu . PDP-11 (bir örnek için) G / Ç kayıtlarını belirli adreslere eşledi. Örneğin, sistem konsolunda bir tuşa basılıp basılmadığını kontrol etmek için bir hafıza konumunu okudunuz. Okunmayı bekleyen veriler olduğunda bu yere bir bit ayarlandı. Daha sonra, basılan tuşun ASCII kodunu almak için belirtilen başka bir konumdan bir bayt okudunuz.

Aynı şekilde, bazı veriler yazdırmak isterseniz, belirtilen başka bir yeri kontrol eder ve çıkış cihazı hazır olduğunda verilerinizi belirtilen başka bir yere yazarsınız.

Bu tür aygıtlar için yazma sürücülerini desteklemek için C, bazı tam sayı türlerini kullanarak rasgele bir konum belirtmenize, bir işaretçiye dönüştürmenize ve bu konumu bellekte okumanıza veya yazmanıza izin verdi.

Elbette, bunun oldukça ciddi bir sorunu var: dünyadaki her makine 1970'lerin başlarından itibaren bir PDP-11 ile aynı şekilde düzenlenmiş bir hatıraya sahip değil. Böylece, bu tamsayıyı aldığınızda, bir işaretçiye dönüştürdüğünüzde ve o işaretçiyi kullanarak okuduğunuzda veya yazdığınızda, ne alacağınız konusunda hiç kimse makul bir garanti veremez. Sadece bariz bir örnek için, okuma ve yazma, donanımdaki kayıtları ayırmak için haritalandırabilir, bu nedenle bir şey yazarsanız (normal belleğe aykırı), sonra tekrar okumaya çalışın, okuduklarınız yazdıklarınızla eşleşmeyebilir.

Bırakan birkaç olasılık görebiliyorum:

1. Tüm olası donanıma bir arabirim tanımlayın - donanımla etkileşim kurmak için herhangi bir şekilde okumak veya yazmak isteyebileceğiniz tüm konumların mutlak adreslerini belirtin.
2. Bu erişim seviyesini yasaklayın ve böyle şeyler yapmak isteyen herkesin assembly dilini kullanması gerektiğine dair karar verin.
3. İnsanların bunu yapmasına izin verin, ancak hedefledikleri donanımın kılavuzlarını okumalarını (örneğin) kullanmalarını sağlayın ve kullandıkları donanıma uygun kodu yazın.

Bunlardan 1, yeterince tartışmaya değmeyecek kadar akıllıca görünüyor. 2 temel olarak dilin temel amacını ortadan kaldırıyor. Bu, üçüncü seçeneği, aslında makul bir şekilde düşünebilecekleri tek seçenek olarak bırakır.

Oldukça sık görülen bir diğer nokta ise tamsayı tiplerinin boyutlarıdır. C int, mimarlık tarafından önerilen doğal boyutta olması gereken "konumu" alır . Öyleyse, eğer 32 bit bir VAX programlıyorsam, intmuhtemelen 32 bit olmalı, ancak 36 bit bir Univac programlıyorsam, intmuhtemelen 36 bit olmalıdır (vb.). Muhtemelen, 8 bit'in katları olarak garanti edilen türleri kullanarak 36 bitlik bir bilgisayar için bir işletim sistemi yazmak makul değildir (ve mümkün olmayabilir). Belki de sadece yüzeysel oluyorum, ama bana öyle geliyor ki 36 bitlik bir makine için bir işletim sistemi yazıyorsam, muhtemelen 36 bitlik bir türü destekleyen bir dil kullanmak istiyorum.

Dil açısından bakıldığında, bu hala daha tanımsız davranışlara yol açmaktadır. 32 bite uyacak en büyük değeri alırsam, 1 eklediğimde ne olacak? Tipik 32 bit donanımda, devrilecek (veya muhtemelen bir tür donanım arızası atacak). Öte yandan, 36 bit donanım üzerinde çalışıyorsa, sadece bir tane ekleyeceğim. Dil yazma işletim sistemlerini destekleyecekse, her iki davranışı da garanti edemezsiniz - hem tür boyutlarının hem de taşma davranışının birinden diğerine değişmesine izin vermek zorundasınız.

Java ve C # bunların hepsini görmezden gelebilir. Yazma işletim sistemlerini desteklemeyi amaçlamıyorlar. Onlarla birlikte birkaç seçeneğiniz var. Birincisi, donanımın istediklerini desteklemektir - 8, 16, 32 ve 64 bit türlerini talep ettikleri için, sadece bu boyutları destekleyen donanımlar oluştururlar. Diğer bir belirgin olasılık, dilin sadece istediği ortamı sağlayan, diğer donanımın ne istediğinden bağımsız olarak çalışabilmesidir.

Çoğu durumda, bu gerçekten bir seçenek veya seçenek değildir. Aksine, birçok uygulama ikisinden de biraz fazlasını yapar. Java'yı normalde bir işletim sisteminde çalışan bir JVM'de çalıştırın. Çoğu zaman, işletim sistemi C ile yazılmamıştır ve JVM C ++ ile yazılmıştır. Eğer JVM bir ARM CPU üzerinde çalışıyorsa, donanımı Java'nın ihtiyaçlarına daha yakından uyarlamak için CPU'nun ARM'in Jazelle uzantılarını içermesi ihtimali oldukça iyidir, bu yüzden yazılımda daha az yapılması gereken ve Java kodunun daha hızlı çalışması (ya da daha az olması) neyse yavaşça).

özet

C ve C ++ tanımsız davranışa sahiptir, çünkü kimse yapmayı amaçladıklarını yapmalarına izin veren kabul edilebilir bir alternatif tanımlamamıştır. C # ve Java farklı bir yaklaşım benimsiyor, ancak bu yaklaşım C ve C ++ hedeflerine (hiç değilse) çok yakışmıyor. Özellikle, hiçbiri en çok seçilen donanım üzerine sistem yazılımı (işletim sistemi gibi) yazmak için makul bir yol sağlamaz. Her ikisi de, işlerini yapmak için mevcut sistem yazılımı tarafından sağlanan tesislere (genellikle C veya C ++ ile yazılmış) bağlıdır.

C Standardının yazarları, okurlarının, açık bir şekilde düşündükleri bir şeyi tanımalarını beklemiş ve yayınlanan gerekçelerinde açıkça belirtmişlerdir, ancak açıkça söylemediler: Komite, derleyici yazarlarının, müşterilerinin ihtiyaçlarını karşılamak için sipariş vermesi gerekmemelidir, Çünkü müşteriler Komite'den daha iyi bir şey bilmelidirler. Belli tür plaformlar için derleyicilerin bir yapıyı belirli bir şekilde işlemesi beklendiği açıksa, Standardın bu tanımsız davranışa yol açtığını söyleyip söylemediğini kimse umursamalıdır. Standardın, uygun derleyicilere uygun bir şekilde bir kod parçasını işlemesini zorunlu kılmaması, programcıların almayan derleyiciler almaya istekli olması gerektiği anlamına gelmez.

Dil tasarımına yönelik bu yaklaşım, derleyici yazarların mallarını ödeme yapan müşterilere satmaları gereken bir dünyada çok iyi çalışıyor. Derleyici yazarların pazarın etkilerinden izole edildiği bir dünyada tamamen parçalanır. 1990'larda popüler olan bir dili yönlendirmek için uygun pazar koşullarının mevcut olacağı şüpheli ve aklı başında bir dil tasarımcısının bu tür pazar koşullarına güvenmek isteyeceği konusunda daha da şüpheli.

C ++ ve c her ikisi de tanımlayıcı standartlara sahiptir (yine de ISO sürümleri).

Hangi sadece dillerin nasıl çalıştığını açıklamak ve dilin ne olduğu hakkında tek bir referans sağlamak için var. Tipik olarak, derleyici satıcıları ve kütüphane yazarları ana ISO standardına dahil olan bazı önerilerde bulunur.

Java ve C # (veya demek istediğinizi varsaydığım Visual C #) kuralcı standartlara sahiptir. Önceden dilde kesin olarak ne olduğunu, nasıl çalıştığını ve izin verilen davranış olarak kabul ettiklerini söylerler.

Bundan daha önemlisi, Java aslında Open-JDK'da bir "referans uygulaması" na sahiptir. ( Roslyn , Visual C # başvuru uygulaması olarak sayılıyor, ancak bunun için bir kaynak bulamadığını düşünüyorum.)

Java'nın durumunda, standartta herhangi bir belirsizlik varsa ve Open-JDK bunu kesin olarak yapar. Open-JDK bunu standart şekilde yapar.

Tanımsız davranış derleyicinin çeşitli mimarlar üzerinde çok verimli kodlar üretmesini sağlar. Erik'in cevabı optimizasyondan bahseder, ancak bunun ötesine geçer.

Örneğin, imzalanmış taşmalar C'de tanımsız davranışlardır. Uygulamada, derleyiciden CPU'nun yürütmesi için basit bir imzalı ek opcode üretmesi beklenirdi ve bu davranış bu CPU'nun yaptığı her şey olurdu.

Bu, C'nin çok iyi performans göstermesine ve çoğu mimaride çok kompakt kod üretmesine izin verdi. Eğer standart imzalı tamsayıların belirli bir şekilde taşması gerektiğini belirtmiş olsaydı, farklı şekilde davranan CPU'ların basit imzalı bir ekleme için daha fazla kod üretmesi gerekirdi.

Bu, C'deki tanımsız davranışların çoğunun sebebi ve intsistemler arasındaki büyüklük gibi şeylerin neden değiştiğinin nedenidir . Intmimariye bağımlıdır ve genellikle a'dan büyük olan en hızlı, en verimli veri türü olarak seçilir char.

C yeniyken, bu düşünceler önemliydi. Bilgisayarlar daha az güçlüydü, çoğu zaman işlem hızı ve hafızası sınırlıydı. Performansın gerçekten önemli olduğu yerlerde C kullanılıyordu ve geliştiricilerin bu tanımsız davranışların gerçekte kendi sistemlerinde ne olacağını bilecek şekilde bilgisayarların nasıl iyi çalıştığını anlamaları bekleniyordu.

Java ve C # gibi diller daha sonra ham performans üzerindeki tanımsız davranışların ortadan kaldırılmasını tercih etti.

Bir anlamda, Java da var. Diyelim ki, Arrays.sort ile yanlış karşılaştırıcı verdiniz. Onu algılaması dışında istisna atabilir. Aksi takdirde, bir diziyi herhangi bir özel olacağı garanti edilmeyen bir şekilde sıralar.

Benzer şekilde, birkaç iş parçacığından değişkeni değiştirirseniz, sonuçlar da tahmin edilemez.

C ++ tanımsız daha fazla durum (veya daha çok işlem tanımlamaya karar verdikten sonra) yapmak ve bunun için bir isme sahip olmak için daha ileri gitti.