1 poin oleh GN⁺ 2024-10-07 | 1 komentar | Bagikan ke WhatsApp

Asal \n

  • Saat menjalankan perintah just foo, justfile menulis byte 0x0A ke file bernama bar
  • just ditulis dalam Rust, dan parser just mengubah token string just yang berisi escape sequence menjadi string UTF-8 melalui fungsi cook_string

Pemrosesan di Rust

  • rustc memproses kode escape dalam fungsi scan_escape
  • rustc ditulis dalam Rust dan dikompilasi sendiri, sehingga penentuan makna '\n' didelegasikan ke rustc
  • Versi awal rustc ditulis dalam OCaml, dan rustc versi OCaml menangani escape karakter di lexer

Pemrosesan di OCaml

  • Kompiler OCaml mengevaluasi \n menjadi \010 lalu menyisipkan hasilnya
  • Karena 0x0A adalah 10, saat kompiler OCaml memproses \n, ia memperoleh nilai byte 0x0A

Kesimpulan

  • Ketika ada escape karakter \n di justfile, biner just menuliskannya ke string akhir dengan menyertakan byte 0x0A
  • Byte 0x0A ini disisipkan oleh rustc, dan asalnya bermula ketika kompiler OCaml pertama kali menyisipkan byte 0x0A ke dalam biner rustc

Ringkasan GN⁺

  • Tulisan ini menjelaskan bagaimana escape karakter \n diubah menjadi byte 0x0A
  • Asal byte 0x0A ditelusuri melalui latar belakang historis kompiler Rust dan OCaml
  • Memberikan wawasan menarik tentang bagaimana kompiler bahasa pemrograman memproses escape karakter
  • Bermanfaat untuk memahami perilaku kompiler Rust dan OCaml

1 komentar

 
GN⁺ 2024-10-07
Komentar Hacker News
  • Seorang pengguna menyebut bahwa pertama kali ia membaca ide ini adalah pada hari ke-42 dari tulisan "How I wrote a self-hosting C compiler in 40 days"

    • Tulisan tersebut menjelaskan bagaimana compiler menafsirkan "\n" dalam literal string
    • Dijelaskan bahwa "\n" tidak memuat informasi kode karakter ASCII secara langsung, melainkan diteruskan saat compiler mengompilasi compiler
    • Disebutkan bahwa karakter baris baru di compiler ini berasal dari GCC
  • Pada sistem EBCDIC, disebutkan bahwa perlu mempertimbangkan bahwa compiler C awal muncul di sistem non-ASCII

    • EBCDIC memiliki karakter NextLine dan LineFeed yang eksplisit
    • Dijelaskan bahwa kode sederhana yang berjalan di ASCII bisa gagal di EBCDIC
    • Di EBCDIC, huruf kecil berada sebelum huruf besar, dan karakter berada sebelum angka, sehingga urutannya berlawanan dengan ASCII
  • Dalam standar C, satu-satunya jaminan terkait encoding karakter adalah bahwa angka '0'-'9' dipetakan secara berurutan dalam urutan menaik

    • Secara teoretis, program C sederhana seharusnya dapat mengompilasi source yang sama di sistem ASCII maupun EBCDIC dan menghasilkan keluaran yang sama
  • Seorang pengguna menyebut kuliah Turing Award Ken Thompson, "Reflections on Trusting Trust", dan menduga tulisan ini mungkin terinspirasi oleh kuliah tersebut

  • Ada yang bertanya-tanya apakah compiler clang memiliki sifat yang sama, dan menjelaskan bahwa hal itu dikodekan secara eksplisit sebagai 10 di lib/Lex/LiteralSupport.cpp

  • Seorang pengguna bertanya-tanya mengapa perlu menyelidiki untuk memahami alasan "\n" dikodekan sebagai 10, karena menurutnya itu sudah sesuai dugaan

  • Disebutkan bahwa tulisan ini terasa seperti persilangan antara literate programming dan puisi, sambil mencoba menjelaskan proses bagaimana byte 0x0A dihasilkan melalui ratusan siklus pembentukan kode

  • Karena bahasa C, seorang pengguna mengira "\0???" adalah escape oktal, dan memahami "\012" sebagai "\x0a" atau "0x0a", serta "\010" sebagai "0x08"

    • Ia menduga OCaml mungkin memiliki escape desimal, bukan escape oktal
  • Diajukan pertanyaan menarik tentang seperti apa kode kita jika ASCII atau string tidak memiliki kode escape

  • Disebutkan bahwa salah satu aturan dalam pemrograman adalah ketika ada dua cara, dan peluang salah satunya benar sementara yang lain salah adalah 50/50, maka pada awalnya kemungkinan besar yang dipilih justru yang salah