yet another place where a linux man page is inaccurate
또 하나의 부정확한 Linux 매뉴얼 페이지
글쓴이는 glibc의 initstate()가 오류 때 NULL을 반환하지 않는다는 기존 주장을 정정합니다. 실제로는 2013년에 동작이 수정됐지만 매뉴얼의 설명은 갱신되지 않았으며, POSIX가 이 함수의 오류 조건을 정의하지 않는다는 점도 빠져 있습니다.
- 주제
에디터 노트
이 사례에서 확인된 문제는 glibc의 현재 동작보다 매뉴얼이 과거 구현을 계속 설명한다는 점입니다. 글쓴이는 직접 코드를 다시 실행해 이전 주장을 바로잡았고, 동시에 POSIX가 오류 조건 자체를 정의하지 않는다는 더 중요한 조건을 찾아냈습니다. 따라서 glibc와 musl의 차이는 POSIX 위반 여부만으로 설명되지 않고, 각 구현이 선택한 확장과 처리 방식의 차이로 읽어야 합니다. 댓글은 문서 유지보수의 자금과 오류 제보 경로를 짚습니다. 제보처로 lore.kernel.org/linux-man을 언급하지만, 댓글 작성자도 이를 자신의 이해에 근거해 설명합니다. 오래된 문서 하나의 오류를 넘어 유지보수 여건을 논하는 관점은 타당하지만, 이 사례만으로 문서 관리 체계 전반의 상태까지 판단할 수는 없습니다.
AI 요약
글쓴이는 이전 글에서 glibc의 initstate()가 오류가 나도 NULL을 반환하지 않아 POSIX 요구사항을 어긴다고 썼습니다. initstate(3) 매뉴얼도 RETURN VALUE 항목에는 실패 시 NULL을 반환한다고 설명하고, BUGS 항목에는 glibc가 다르게 동작한다고 적었습니다. 독자의 제보를 받고 코드를 다시 실행한 결과, NULL을 확인하는 단언문은 성공했습니다. glibc는 2013년에 동작을 고쳤지만 매뉴얼 내용은 갱신되지 않았습니다.
글쓴이는 기존 주장을 철회하면서 매뉴얼에 빠진 정보도 덧붙입니다. POSIX는 initstate()의 오류를 정의하지 않습니다. glibc가 오류 때 errno를 설정하는 동작은 확장이며, state 인수가 NULL일 때 오류로 처리하는 동작도 POSIX가 아니라 glibc의 확장입니다. 반면 musl은 POSIX를 엄격히 따르므로 오류 때 errno를 설정하지 않고, NULL 포인터를 전달하면 세그멘테이션 오류가 발생한다고 설명합니다.
Lobsters 반응
- @jvns — 최근 오픈소스 문서 문제를 생각할 때, 누가 문서를 관리하는지, 그 작업에 예산이 지원되는지, 문서 오류를 어떤 경로로 제보할 수 있는지 살펴보려고 합니다. 문서 작업은 자금 지원이 특히 부족하기 때문입니다. 제가 알기로 Linux man pages는 한동안 The Linux Programming Interface의 저자 Michael Kerrisk가 관리했고, 이후 Alejandro Colomar가 맡았습니다. Colomar는 2020년부터 2024년까지 자원봉사자로 문서를 관리했습니다. 지금은 Linux Foundation의 지원을 받는 것 같습니다. 오류 제보는 lore.kernel.org/linux-man을 이용하는 것으로 보입니다. 최근 Git 문서 문제를 다루며 lore.kernel.org에 글을 올리는 방법을 배우고 있는데, 진입 장벽이 높지만 해볼 만하다고 생각합니다.
- @travisgriggs — 주석은 거짓말합니다! (https://wiki.c2.com/?CommentCostsAndBenefits)
원문: Lobsters / 번역·요약: Trawling