여섯 번째 이름

probe 자체는 달력 산술이었다 —— 월간 달력 너머에 있는, 날짜 처리의 부분. Mere 에 date 형은 없으므로 날짜는 연 · 월 · 일의 tuple 이고, probe 의 핵심은 civil date 와 통일(通日)의 상호 변환이었다. epoch 로부터의 일수를, 정수 나눗셈과 나머지에 강하게 기대는 알고리즘으로 계산한다 —— 그것이 재려던 축이다. probe 자체의 성적은 완승이었다. 알려진 날짜의 요일은 올바르게 나왔고, 두 날짜 사이의 간격은 참조 구현과 일 단위로 일치했으며, 윤년 경계를 넘는 하루의 덧셈은 윤년에 2 월 29 일을, 평년에 3 월 1 일을 돌려주었고, 연속하는 3 만 개의 통일 —— 약 82 년분 —— 의 round-trip 은 완전히 역전되었다. interp 에서도 C backend 에서도 동일하게. modular 산술이 아플 것이라는 사전의 의심은, 적어도 양수 범위에서는 빗나갔다. tuple 로서의 날짜는 잘 읽혔다.

y0 이라는 이름의 매개변수

마찰은 예상 밖의 방향에서 왔다. 변환 함수의 매개변수는 y0 이라 이름 붙어 있었다 —— 조정된 연도, 알고리즘 자신의 제시에서 오는 자연스러운 이름 —— 그리고 C backend 에서 프로그램은 컴파일을 거부했다. y0 은 C 수학 라이브러리의 Bessel 함수이고, backend 는 math 헤더를 include 한다. C 이름공간과 충돌한 여섯 번째 이름이었다. index, remove, acct, dup, run, 그리고 이번엔 y0. 모두 같은 방식으로 발견되었다. 평범한 프로그램이, C 가 이미 차지하고 있던 평범한 단어를 씀으로써.

목록에 올라 있는데도 깨진다

이번이 달랐던 것은 y0 이 이미 예약 목록에 올라 있었다는 점이다. Bessel 함수들은 오래전에 방어적으로 추가되어 있었다. sanitizer 는 그 이름이 위험하다는 것을 알았고 개명했을 것이다 —— 그러나 plain 한 최상위 커링 함수의 매개변수 선언을 emit 하는 코드 경로가 sanitizer 에게 한 번도 묻지 않았다. 그래서 선언은 raw 의 y0 이라 말하고, body 는 —— 그 매개변수를 돌려주는 closure 에 포획할 때 —— 새니타이즈된 철자를 참조했으며, C 컴파일러는 불일치를 미선언 식별자로 거부했다. 두 릴리스 전, gzip probe 가 매개변수를 index 라 이름 붙였을 때, 완전히 같은 def/use 불일치가 lifted 함수와 closure adapter 에 대해 발견되고 수정되었다. 이것은 다른 문으로 들어온 같은 버그다. 목록에 없는 이름이 아니라, 목록을 보지 않는 경로.

수정은 한 줄 —— plain 경로를, 다른 경로들이 이미 쓰는 것과 같은 매개변수 포매터에 통과시킨다 —— 였고, probe 는 어디서나 초록이 되었다. 그러나 수정보다 장부가 더 중요하다. 여섯 개의 충돌은 이제 두 종류의 고장으로 나뉜다. 손으로 관리하는 목록이 아직 갖지 못한 이름과, 목록에 상담하지 않은 emission 경로. 목록을 키우는 것은 첫째를 고치고 둘째에는 아무것도 하지 않는다. 경로를 감사하는 것은 둘째를 고치고 첫째에는 아무것도 하지 않는다. 지금까지의 수정은 모두 사례를 다뤘다. 목록 옆의 소스 주석은 몇 달 전부터, 목록은 본질적으로 불완전하고 robust 한 수정은 모든 사용자 이름을 이름공간화하는 것이라고 인정하고 있었다 —— 그때마다 너무 크다며 미뤄진 채로. 여섯은 그 미룸이 신중함이기를 그만두고 부채가 되기 시작하는 수로 느껴졌다. 다음 릴리스는 목록을 지운다.