Null ile sonlandırılmış dize - Null-terminated string

Ayrıca bakınız: Dize (bilgisayar bilimi) § Null ile sonlandırıldı

İçinde bilgisayar Programlama, bir boş sonlu dize bir karakter dizesi olarak saklandı dizi karakterleri içeren ve bir ile biten boş karakter ('\0', NUL olarak adlandırılır ASCII ). Alternatif isimler C dizesianlamına gelen C programlama dili ve ASCIIZ (C, ASCII dışındaki kodlamaları kullanabilmesine rağmen).

Bir C dizgisinin uzunluğu, (ilk) NUL baytı aranarak bulunur. Bu O alırken yavaş olabilir (n) (doğrusal zaman ) dize uzunluğuna göre. Ayrıca, bir dizenin NUL karakteri içeremeyeceği anlamına gelir (bellekte bir NUL vardır, ancak dizede "içinde" değil, son karakterden sonra gelir).

Tarih

Boş sonlandırılmış dizeler, .ASCIZ Direktifi PDP-11 montaj dilleri ve ASCIZ Direktifi MAKRO-10 için makro birleştirme dili PDP-10. Bunlar C programlama dilinin geliştirilmesinden öncedir, ancak diğer dizge biçimleri sıklıkla kullanılmıştır.

C (ve türetildiği diller) geliştirildiğinde, bellek son derece sınırlıydı, bu nedenle bir dizginin uzunluğunu depolamak için yalnızca bir bayt ek yük kullanmak cazipti. O zamanın tek popüler alternatifi, genellikle "Pascal dizisi" olarak adlandırılır (daha modern bir terim "uzunluk önekli "), dizinin uzunluğunu saklamak için bir baş bayt kullandı. Bu, dizenin NUL içermesine izin verir ve uzunluğu bulmanın yalnızca bir bellek erişimi gerektirmesini sağlar (O (1) (sabit) zaman ), ancak dize uzunluğu 255 karakterle sınırlıdır (8 bit bayt kullanan bir makinede). C tasarımcısı Dennis Ritchie zaten yerleşik olan NUL sonlandırma sözleşmesini izlemeyi seçti BCPL, bir ipin uzunluğundaki sınırlamadan kaçınmak ve sayımın sürdürülmesi deneyimine göre, bir sonlandırıcı kullanmaktan daha az uygun göründü.[1]

Bunun CPU üzerinde biraz etkisi oldu komut seti tasarım. 1970'ler ve 1980'lerdeki bazı CPU'lar, örneğin Zilog Z80 ve ARALIK VAX, uzunluk önekli dizeleri işlemek için özel talimatlara sahipti. Bununla birlikte, NUL ile sonlandırılmış dizge ilgi gördükçe, CPU tasarımcıları, örneğin IBM'in "Logical String Assist" talimatlarını ES / 9000 1992'de 520.

FreeBSD geliştirici Poul-Henning Kampı, yazıyor ACM Sırası, daha sonra boş sonlandırılmış dizgelerin 2 baytlık (bir bayt değil) uzunluğa göre kazandığı zaferi "şimdiye kadarki en pahalı tek baytlık hata" olarak adlandıracaktır.[2]

Sınırlamalar

Uygulanması basit olsa da, bu gösterim hatalara ve performans sorunlarına açıktır.

NUL sonlandırması tarihsel olarak yarattı güvenlik sorunları.[3] Bir dizenin ortasına eklenen bir NUL baytı onu beklenmedik bir şekilde kesecektir.[4] Yaygın bir hata, NUL için ek alan ayırmamaktı, bu nedenle bitişik bellek üzerine yazılmıştır. Bir diğeri, NUL'u hiç yazmamaktı, ki bu genellikle test sırasında tespit edilemiyordu, çünkü aynı bellek bloğunun önceki kullanımından dolayı şans eseri bir NUL zaten mevcuttu. Uzunluğu bulma masrafından dolayı, birçok program bir dizeyi sabit boyuta kopyalamadan önce uğraşmadı. tampon, neden oluyor arabellek taşması çok uzun olsaydı.

Bir NUL'un saklanamaması, dizi verilerinin ve ikili verilerin ayrı tutulmasını ve farklı işlevler tarafından işlenmesini gerektirir (ikincisi, verinin uzunluğunun da sağlanmasını gerektirir). Bu, yanlış işlev kullanıldığında kod fazlalığına ve hatalara neden olabilir.

Uzunluğu bulmayla ilgili hız problemleri genellikle onu başka bir işlemle birleştirerek hafifletilebilir.n) neyse, örneğin strlcpy. Ancak, bu her zaman sezgisel bir API.

Karakter kodlamaları

Boş sonlandırılmış dizeler, kodlamanın herhangi bir yerde sıfır bayt (0x00) kullanmamasını gerektirir, bu nedenle mümkün olan her şeyi saklamak mümkün değildir. ASCII veya UTF-8 dize.[5][6][7] Bununla birlikte, ASCII veya UTF-8'in alt kümesini - NUL karakteri hariç her karakter - boş sonlandırılmış dizelerde depolamak yaygındır. Bazı sistemler "değiştirilmiş UTF-8 "NUL karakterini sıfır olmayan iki bayt (0xC0, 0x80) olarak kodlayan ve böylece tüm olası dizelerin depolanmasına izin veren. Bu, UTF-8 standardı tarafından izin verilmez, çünkü aşırı uzun kodlama ve bir güvenlik riski olarak görülüyor. UTF-8'de kullanılmayan 0xFE veya 0xFF gibi bazı başka baytlar dizenin sonu olarak kullanılabilir.

UTF-16 2 baytlık tamsayılar kullanır ve her iki bayt da sıfır olabilir (ve aslında her biri bayt, ASCII metnini temsil ederken) boş sonlandırılmış bir bayt dizesinde saklanamaz. Ancak, bazı diller 16 bitlik bir dizi uygular UTF-16 16 bitlik NUL karakteriyle sonlanan karakterler. (Yine, tek bir sıfır kod birimi olarak kodlayan NUL karakteri, saklanamayan tek karakterdir. UTF-16'nın herhangi bir alternatif sıfır kodlaması yoktur).

İyileştirmeler

C dizisi işlemeyi daha az hataya açık hale getirmek için birçok girişimde bulunulmuştur. Bir strateji, daha güvenli işlevler eklemektir. strdup ve strlcpy, İken güvenli olmayan işlevlerin kullanımını reddetme gibi alır. Bir diğeri, C dizgilerinin etrafına nesne yönelimli bir sarmalayıcı eklemektir, böylece yalnızca güvenli aramalar yapılabilir. Bununla birlikte, güvenli olmayan işlevleri yine de çağırmak mümkündür.

Çoğu modern kitaplık, C dizgilerini 32-bit veya daha büyük uzunluk değeri içeren bir yapıyla değiştirir (uzunluk önekli dizeler için düşünülenden çok daha fazlası) ve çoğu zaman başka bir işaretçi, bir referans sayısı ve hatta dönüşümü hızlandırmak için bir NUL ekler. bir C dizesine geri dönün. Bellek artık çok daha büyük, öyle ki her dizeye 3 (veya 16 veya daha fazla) bayt eklenmesi gerçek bir sorunsa, yazılım o kadar çok küçük dizgiyle uğraşmak zorunda kalacak ki başka bir depolama yöntemi daha fazla bellek tasarrufu sağlayacaktır. (örneğin o kadar çok kopya olabilir ki karma tablo daha az bellek kullanır). Örnekler şunları içerir: C ++ Standart Şablon Kitaplığı std :: string, Qt QString, MFC CStringve C tabanlı uygulama CFString itibaren Çekirdek Vakfı yanı sıra onun Amaç-C kardeş NSString itibaren Yapı temeli, ikisi de Apple tarafından. Dizeleri depolamak için daha karmaşık yapılar da kullanılabilir. İp.

Ayrıca bakınız

Referanslar

  1. ^ Dennis M. Ritchie (1993). [C dilinin gelişimi]. Proc. 2. Programlama Dilleri Konf.
  2. ^ Kamp, Poul-Henning (25 Temmuz 2011), "En Pahalı Tek Baytlık Hata", ACM Sırası, 9 (7), ISSN  1542-7730, alındı 2 Ağustos 2011
  3. ^ Rain Forest Puppy (9 Eylül 1999). "Perl CGI sorunları". Phrack Dergisi. artofhacking.com. 9 (55): 7. Alındı 3 Ocak 2016.
  4. ^ https://security.stackexchange.com/questions/48187/null-byte-injection-on-php
  5. ^ "UTF-8, bir ISO 10646 dönüştürme biçimi". Alındı 19 Eylül 2013.
  6. ^ "Unicode / UTF-8 karakter tablosu". Alındı 13 Eylül 2013.
  7. ^ Kuhn, Markus. "UTF-8 ve Unicode SSS". Alındı 13 Eylül 2013.