# Whence '\n'?

> Clean Markdown view of GeekNews topic #17114. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17114](https://news.hada.io/topic?id=17114)
- GeekNews Markdown: [https://news.hada.io/topic/17114.md](https://news.hada.io/topic/17114.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-10-07T10:02:30+09:00
- Updated: 2024-10-07T10:02:30+09:00
- Original source: [rodarmor.com](https://rodarmor.com/blog/whence-newline/)
- Points: 1
- Comments: 1

## Topic Body

### '\n'의 출처

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

#### Rust의 처리

- `rustc`는 `scan_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의 컴파일러 동작을 이해하는 데 도움이 되는 글임

## Comments



### Comment 29767

- Author: neo
- Created: 2024-10-07T10:02:30+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41748664) 
- 한 사용자는 자신이 처음 이 아이디어를 읽은 곳이 "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이라면 처음에는 틀릴 가능성이 높다는 것임을 언급함