1P by neo 2달전 | favorite | 댓글 1개

'\n'의 출처

  • just foo 명령을 실행하면, justfile0x0A 바이트를 bar라는 파일에 기록함
  • just는 Rust로 작성되었으며, just 파서는 cook_string이라는 함수를 통해 escape 시퀀스를 포함하는 just 문자열 토큰을 UTF-8 문자열로 변환함

Rust의 처리

  • rustcscan_escape라는 함수에서 escape 코드를 처리함
  • rustc는 Rust로 작성되어 자체 컴파일되며, '\n'의 의미를 파악하기 위해 rustc에 위임함
  • 초기 버전의 rustc는 OCaml로 작성되었으며, OCaml 버전의 rustc는 lexer에서 문자 escape를 처리함

OCaml의 처리

  • OCaml 컴파일러는 \n\010으로 평가하여 결과를 삽입함
  • 0x0A는 10이므로, OCaml 컴파일러가 \n을 처리할 때 0x0A 바이트 값을 얻게 됨

결론

  • justfile에서 \n 문자 escape가 있을 때, just 바이너리는 0x0A 바이트를 포함하여 최종 문자열에 기록함
  • 0x0A 바이트는 rustc에 의해 삽입되었으며, 이는 OCaml 컴파일러가 처음으로 rustc 바이너리에 0x0A 바이트를 삽입한 것에서 시작됨

GN⁺의 정리

  • 이 글은 \n 문자 escape가 어떻게 0x0A 바이트로 변환되는지를 설명함
  • Rust와 OCaml 컴파일러의 역사적 배경을 통해 0x0A 바이트의 출처를 추적함
  • 프로그래밍 언어의 컴파일러가 어떻게 문자 escape를 처리하는지에 대한 흥미로운 통찰을 제공함
  • Rust와 OCaml의 컴파일러 동작을 이해하는 데 도움이 되는 글임
Hacker News 의견
  • 한 사용자는 자신이 처음 이 아이디어를 읽은 곳이 "How I wrote a self-hosting C compiler in 40 days"라는 글의 42일차였음을 언급함

    • 이 글에서는 컴파일러가 문자열 리터럴에서 "\n"을 해석하는 방법을 설명함
    • "\n"은 실제 ASCII 문자 코드 정보를 포함하지 않으며, 컴파일러가 컴파일러를 컴파일할 때 전달된다고 설명함
    • 이 컴파일러의 줄 바꿈 문자는 GCC에서 유래되었음을 언급함
  • EBCDIC 시스템에서는 초기 C 컴파일러가 ASCII가 아닌 시스템에서 등장했음을 고려해야 한다고 언급함

    • EBCDIC는 명시적인 NextLine과 LineFeed 문자를 가지고 있었음
    • ASCII에서는 작동하는 간단한 코드가 EBCDIC에서는 실패할 수 있음을 설명함
    • EBCDIC에서는 소문자가 대문자보다 앞에 오고, 문자가 숫자보다 앞에 오는 등 ASCII와 정반대의 정렬을 가짐
  • C 표준에서 문자 인코딩에 대한 유일한 보장은 '0'-'9' 숫자가 연속적인 오름차순으로 매핑된다는 것임

    • 이론적으로 간단한 C 프로그램은 ASCII나 EBCDIC 시스템에서 동일한 소스를 컴파일하여 동일한 출력을 생성해야 함
  • 한 사용자는 Ken Thompson의 Turing Award 강연 "Reflections on Trusting Trust"를 언급하며 이 글이 그 강연에서 영감을 받았을 것이라고 추측함

  • clang 컴파일러가 동일한 속성을 가지고 있는지 궁금해하며, 이는 lib/Lex/LiteralSupport.cpp에서 명시적으로 10으로 코딩되어 있음을 설명함

  • 한 사용자는 "\n"이 10으로 인코딩된 이유를 이해하기 위해 왜 탐구가 필요했는지 궁금해하며, 이는 예상된 것이라고 생각함

  • 이 글이 문학적 프로그래밍과 시의 교차점처럼 읽힌다고 언급하며, 코드 생성의 수백 사이클을 통해 0x0A 바이트가 생성되는 과정을 설명하려고 한다고 함

  • C 언어 때문에 "\0???"가 8진수 이스케이프라고 생각했으며, "\012"는 "\x0a" 또는 "0x0a"로, "\010"은 "0x08"로 인식했다고 설명함

    • OCaml이 8진수 이스케이프가 아닌 10진수 이스케이프를 가지고 있을 수 있다고 추측함
  • ASCII나 문자열에 이스케이프 코드가 없었다면 우리의 코드가 어떻게 보였을지에 대한 흥미로운 질문을 제기함

  • 프로그래밍의 한 가지 규칙은 두 가지 방법이 있을 때, 하나가 맞고 다른 하나가 틀릴 확률이 50/50이라면 처음에는 틀릴 가능성이 높다는 것임을 언급함