'\n' Nereden Geliyor?

 (rodarmor.com)
1 puan yazan GN⁺ 2024-10-07 | 1 yorum | WhatsApp'ta paylaş

'\n' karakterinin kökeni

  • just foo komutu çalıştırıldığında, justfile 0x0A baytını bar adlı bir dosyaya yazar
  • just Rust ile yazılmıştır ve just ayrıştırıcısı, escape dizileri içeren just dize token’larını cook_string adlı bir işlev üzerinden UTF-8 dizelerine dönüştürür

Rust tarafındaki işlem

  • rustc, escape kodlarını scan_escape adlı işlevde işler
  • rustc Rust ile yazılmıştır ve kendi kendini derler; '\n' ifadesinin anlamını belirlemek için işi rustc'ye devreder
  • rustc'nin ilk sürümleri OCaml ile yazılmıştı ve rustc'nin OCaml sürümü karakter escape’lerini lexer içinde işlerdi

OCaml tarafındaki işlem

  • OCaml derleyicisi \n ifadesini \010 olarak değerlendirir ve sonucu yerleştirir
  • 0x0A, 10 olduğundan, OCaml derleyicisi \n ifadesini işlerken 0x0A bayt değerini elde eder

Sonuç

  • justfile içinde \n karakter escape’i bulunduğunda, just ikilisi bunu 0x0A baytını içerecek şekilde nihai dizeye yazar
  • Bu 0x0A baytı rustc tarafından eklenmiştir; bunun başlangıcı da OCaml derleyicisinin ilk kez rustc ikilisine 0x0A baytını yerleştirmesine dayanır

GN⁺ özeti

  • Bu yazı, \n karakter escape’inin nasıl 0x0A baytına dönüştüğünü açıklar
  • Rust ve OCaml derleyicilerinin tarihsel arka planı üzerinden 0x0A baytının kökeninin izi sürülür
  • Programlama dili derleyicilerinin karakter escape’lerini nasıl işlediğine dair ilgi çekici bir içgörü sunar
  • Rust ve OCaml derleyici davranışını anlamaya yardımcı olan bir yazıdır

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-07
Hacker News görüşleri

  • Bir kullanıcı, bu fikri ilk kez "How I wrote a self-hosting C compiler in 40 days" başlıklı yazının 42. gününde okuduğunu belirtiyor

    • Yazıda, derleyicinin string literal içindeki "\n" ifadesini nasıl yorumladığı açıklanıyor
    • "\n" ifadesinin gerçek ASCII karakter kodu bilgisini içermediği, bunun derleyici derleyiciyi derlerken aktarıldığı belirtiliyor
    • Bu derleyicideki yeni satır karakterinin GCC'den geldiği söyleniyor

  • EBCDIC sistemlerinde, ilk C derleyicilerinin ASCII olmayan sistemlerde ortaya çıktığının hesaba katılması gerektiği belirtiliyor

    • EBCDIC, açıkça tanımlanmış NextLine ve LineFeed karakterlerine sahipti
    • ASCII'de çalışan basit kodların EBCDIC'de başarısız olabileceği açıklanıyor
    • EBCDIC'de küçük harfler büyük harflerden önce, harfler de rakamlardan önce gelir; yani sıralama ASCII'nin tam tersidir

  • C standardında karakter kodlamasına dair tek garanti, '0' ile '9' arasındaki rakamların artan sırada ve bitişik olarak eşlenmesidir

    • Teorik olarak, basit bir C programı aynı kaynak kodla ASCII ya da EBCDIC sistemlerinde derlenip aynı çıktıyı üretmelidir

  • Bir kullanıcı, Ken Thompson'ın Turing Award konuşması "Reflections on Trusting Trust"a değinerek bu yazının o konuşmadan ilham almış olabileceğini tahmin ediyor

  • clang derleyicisinin de aynı özelliğe sahip olup olmadığını merak ediyor ve bunun lib/Lex/LiteralSupport.cpp içinde açıkça 10 olarak kodlandığını belirtiyor

  • Bir kullanıcı, "\n" ifadesinin neden 10 olarak kodlandığını anlamak için neden ayrıca araştırma gerektiğini sorguluyor; ona göre bu zaten beklenen bir şey

  • Yazının, edebi programlama ile şiirin kesişimi gibi okunduğu ve yüzlerce kod üretim döngüsü boyunca 0x0A baytının nasıl üretildiğini açıklamaya çalıştığı söyleniyor

  • Bir kullanıcı, C dili yüzünden "\0???" ifadesini sekizlik kaçış dizisi olarak düşündüğünü, "\012" ifadesini "\x0a" veya "0x0a", "\010" ifadesini ise "0x08" olarak algıladığını anlatıyor

    • OCaml'de sekizlik değil onluk kaçış dizileri olabileceğini tahmin ediyor

  • ASCII'de ya da string'lerde kaçış kodları olmasaydı kodumuzun nasıl görüneceğine dair ilginç bir soru ortaya atılıyor

  • Programlamadaki kurallardan birinin şu olduğu söyleniyor: İki yöntem varsa ve birinin doğru, diğerinin yanlış olma ihtimali 50/50 ise, ilk denemede yanlışı seçme olasılığın daha yüksektir