Woher kommt `\n`?

Der Ursprung von \n

• Wenn der Befehl just foo ausgeführt wird, schreibt justfile das Byte 0x0A in eine Datei namens bar
• just ist in Rust geschrieben, und der just-Parser wandelt just-String-Tokens, die Escape-Sequenzen enthalten, über eine Funktion namens cook_string in UTF-8-Strings um

Verarbeitung in Rust

• rustc verarbeitet Escape-Codes in einer Funktion namens scan_escape
• rustc ist in Rust geschrieben und kompiliert sich selbst; um die Bedeutung von '\n' zu verstehen, wird dies an rustc delegiert
• Frühere Versionen von rustc waren in OCaml geschrieben, und die OCaml-Version von rustc verarbeitete Zeichen-Escapes im Lexer

Verarbeitung in OCaml

• Der OCaml-Compiler wertet \n als \010 aus und fügt das Ergebnis ein
• 0x0A ist 10, daher erhält der OCaml-Compiler beim Verarbeiten von \n den Byte-Wert 0x0A

Fazit

• Wenn es in einem justfile das Zeichen-Escape \n gibt, schreibt das just-Binary den endgültigen String einschließlich des Bytes 0x0A
• Dieses Byte 0x0A wurde von rustc eingefügt, und das geht darauf zurück, dass der OCaml-Compiler ursprünglich das Byte 0x0A in das rustc-Binary eingefügt hat

Zusammenfassung von GN⁺

• Dieser Artikel erklärt, wie das Zeichen-Escape \n in das Byte 0x0A umgewandelt wird
• Vor dem historischen Hintergrund der Rust- und OCaml-Compiler wird der Ursprung des Bytes 0x0A nachverfolgt
• Er bietet einen interessanten Einblick darin, wie Compiler von Programmiersprachen Zeichen-Escapes verarbeiten
• Ein hilfreicher Text, um das Compiler-Verhalten von Rust und OCaml besser zu verstehen

[GN⁺]

Hacker-News-Kommentare

• Ein Nutzer erwähnt, dass er diese Idee zum ersten Mal am 42. Tag des Artikels "How I wrote a self-hosting C compiler in 40 days" gelesen habe

  • In diesem Artikel wird erklärt, wie der Compiler "\\n" in String-Literalen interpretiert
  • Es wird erklärt, dass "\\n" selbst keine tatsächliche ASCII-Zeichencode-Information enthält, sondern vom Compiler übergeben wird, wenn er den Compiler kompiliert
  • Es wird erwähnt, dass das Zeilenumbruchzeichen dieses Compilers von GCC stammt

• Bei EBCDIC-Systemen müsse man berücksichtigen, dass frühe C-Compiler auf Systemen entstanden seien, die nicht ASCII verwendeten

  • EBCDIC hatte explizite NextLine- und LineFeed-Zeichen
  • Es wird erklärt, dass einfacher Code, der unter ASCII funktioniert, unter EBCDIC fehlschlagen kann
  • Unter EBCDIC stehen Kleinbuchstaben vor Großbuchstaben, und Buchstaben vor Ziffern – also in einer zur ASCII-Reihenfolge gegensätzlichen Sortierung

• Die einzige Garantie des C-Standards bezüglich der Zeichenkodierung ist, dass die Ziffern '0'-'9' fortlaufend in aufsteigender Reihenfolge abgebildet werden

  • Theoretisch sollte ein einfaches C-Programm auf ASCII- wie auf EBCDIC-Systemen aus derselben Quelle kompiliert werden können und dieselbe Ausgabe erzeugen

• Ein Nutzer erwähnt Ken Thompsons Turing-Award-Vortrag "Reflections on Trusting Trust" und vermutet, dass dieser Artikel davon inspiriert wurde

• Es wird gefragt, ob der clang-Compiler dieselbe Eigenschaft besitzt, und erklärt, dass dies in lib/Lex/LiteralSupport.cpp explizit als 10 kodiert ist

• Ein Nutzer fragt sich, warum man überhaupt untersuchen musste, weshalb "\\n" als 10 kodiert ist, da er das für erwartbar hält

• Es wird erwähnt, dass sich der Artikel wie ein Schnittpunkt von literarischem Programmieren und Poesie liest, und dass er zu erklären versucht, wie durch Hunderte Zyklen der Code-Erzeugung das Byte 0x0A entsteht

• Ein Nutzer erklärt, dass er wegen der Sprache C "\\0???" für einen oktalen Escape hielt und "\\012" als "\\x0a" oder "0x0a" sowie "\\010" als "0x08" verstand

  • Er vermutet, dass OCaml statt oktaler Escape-Sequenzen dezimale Escape-Sequenzen haben könnte

• Es wird die interessante Frage aufgeworfen, wie unser Code aussehen würde, wenn ASCII oder Strings keine Escape-Codes hätten

• Ein Nutzer erwähnt eine Regel des Programmierens: Wenn es zwei Möglichkeiten gibt und die Chance 50/50 steht, dass eine richtig und die andere falsch ist, liegt man anfangs meist eher falsch damit