1 points par GN⁺ 2024-10-07 | 1 commentaires | Partager sur WhatsApp

L’origine de \n

  • Lorsque la commande just foo est exécutée, le justfile écrit l’octet 0x0A dans un fichier nommé bar
  • just est écrit en Rust, et l’analyseur de just convertit les tokens de chaîne just contenant des séquences d’échappement en chaînes UTF-8 via une fonction appelée cook_string

Traitement par Rust

  • rustc traite les codes d’échappement dans une fonction appelée scan_escape
  • rustc est écrit en Rust et se compile lui-même, en déléguant à rustc la compréhension de la signification de '\n'
  • Les premières versions de rustc étaient écrites en OCaml, et la version OCaml de rustc traitait les échappements de caractères dans le lexer

Traitement par OCaml

  • Le compilateur OCaml évalue \n en \010 puis insère le résultat
  • 0x0A vaut 10, donc lorsque le compilateur OCaml traite \n, il obtient la valeur d’octet 0x0A

Conclusion

  • Lorsqu’un échappement de caractère \n apparaît dans un justfile, le binaire just l’écrit dans la chaîne finale en y incluant l’octet 0x0A
  • Cet octet 0x0A a été inséré par rustc, ce qui remonte au moment où le compilateur OCaml a, pour la première fois, inséré l’octet 0x0A dans le binaire rustc

Résumé de GN⁺

  • Cet article explique comment l’échappement de caractère \n est converti en octet 0x0A
  • Il retrace l’origine de l’octet 0x0A à travers le contexte historique des compilateurs Rust et OCaml
  • Il offre un éclairage intéressant sur la manière dont les compilateurs de langages de programmation traitent les échappements de caractères
  • C’est un article utile pour comprendre le fonctionnement des compilateurs de Rust et d’OCaml

1 commentaires

 
GN⁺ 2024-10-07
Discussion sur Hacker News
  • Un utilisateur mentionne que la première fois qu’il a lu cette idée, c’était au 42e jour de l’article « How I wrote a self-hosting C compiler in 40 days »

    • Cet article explique comment le compilateur interprète "\\n" dans un littéral de chaîne
    • Il explique que "\\n" ne contient pas l’information réelle du code de caractère ASCII, mais qu’elle est transmise lorsque le compilateur compile le compilateur
    • Il mentionne que le caractère de saut de ligne de ce compilateur provient de GCC
  • Il est mentionné que, sur les systèmes EBCDIC, il faut tenir compte du fait que les premiers compilateurs C sont apparus sur des systèmes non ASCII

    • EBCDIC possédait des caractères NextLine et LineFeed explicites
    • Il est expliqué qu’un code simple qui fonctionne en ASCII peut échouer en EBCDIC
    • En EBCDIC, les minuscules viennent avant les majuscules, et les lettres avant les chiffres, soit un ordre exactement inverse de celui d’ASCII
  • Dans le standard C, la seule garantie concernant l’encodage des caractères est que les chiffres '0'-'9' sont mappés de façon contiguë en ordre croissant

    • En théorie, un programme C simple devrait produire la même sortie à partir du même code source compilé sur un système ASCII ou EBCDIC
  • Un utilisateur mentionne la conférence de remise du prix Turing de Ken Thompson, « Reflections on Trusting Trust », et suppose que cet article en est peut-être inspiré

  • Quelqu’un se demande si le compilateur clang possède la même propriété, et explique que cela est codé explicitement comme 10 dans lib/Lex/LiteralSupport.cpp

  • Un utilisateur se demande pourquoi il a fallu enquêter pour comprendre pourquoi "\\n" est encodé comme 10, estimant que c’était attendu

  • Il est mentionné que cet article se lit comme à l’intersection entre programmation lettrée et poésie, et qu’il tente d’expliquer comment l’octet 0x0A est généré à travers des centaines de cycles de génération de code

  • Un utilisateur explique qu’à cause du langage C, il pensait que "\\0???" était une séquence d’échappement octale, et qu’il interprétait "\\012" comme "\\x0a" ou "0x0a", et "\\010" comme "0x08"

    • Il suppose qu’OCaml pourrait avoir des séquences d’échappement décimales plutôt qu’octales
  • Une question intéressante est soulevée sur ce à quoi notre code ressemblerait si ASCII ou les chaînes de caractères n’avaient pas de codes d’échappement

  • Un utilisateur mentionne qu’une règle de la programmation est que, lorsqu’il existe deux façons de faire, si la probabilité qu’une soit correcte et l’autre incorrecte est de 50/50, alors il est plus probable qu’on choisisse d’abord la mauvaise