Hacker News 의견

• Rust의 다음 에디션에서 환경 설정자를 안전하지 않게 만들 예정임. 이는 충돌을 일으키는 크레이트에 영향을 줄 수 있음

  • Rust 표준 라이브러리에서 set_var와 remove_var는 2024년 에디션에서 unsafe {} 블록을 사용해야 함
  • 현재 문서에는 안전성 문제를 언급하고 있지만, 원래 이러한 함수들을 안전하게 만든 것은 실수였음

• glibc에 대한 패치가 getenv를 더 안전하게 만들었지만, C는 여전히 환경에 직접 접근을 허용하여 완전히 안전하지는 않음

  • C 표준 라이브러리 유지보수자들이 setenv를 멀티스레드 안전하게 만들기를 꺼려하지만, 최소한 새로운 스레드 안전 API가 정의되어야 함
  • Musl의 유지보수자가 이 문제를 해결할 수 없다고 확신하지 않음

• 리눅스에서 환경 관련 버그를 겪는 것은 일종의 통과의례처럼 여겨짐

  • Linus와 커널은 POSIX 버그를 해결하는 데 실용적이지만, glibc는 여전히 뒤처져 있음
  • getenv_r()를 제공하고 setenv()와 동기화하며 컴파일/링크 시 경고를 제공하는 것이 문제 해결에 도움이 되었을 것임

• 환경 변수를 사용한 설정은 "12-factor app" 운동의 일부였지만, 이는 어리석은 방법이라고 생각함

  • 환경 변수 대신 YAML과 같은 설정 파일을 사용하는 것이 더 나은 방법이라고 생각함

• Amazon AWS에서 실행되는 CI 머신은 실제 루트 사용자를 제공하여 장점이 있음

  • 클라우드와 컨테이너 없이 로컬에서 코드 빌드 및 디버그 능력을 잃은 것 같음

• 비직관적인 버그를 파헤치는 훌륭한 기사임

  • 이러한 상세한 문제 해결 보고서는 직접 해보는 것과 가장 가까운 경험을 제공함

• env::set_var는 이제 안전하지 않음

  • 단일 스레드 프로그램에서는 안전하게 호출할 수 있음
  • Windows에서는 단일 및 멀티 스레드 프로그램 모두에서 항상 안전함
  • 다른 운영 체제의 멀티 스레드 프로그램에서는 set_var 또는 remove_var를 사용하지 않는 것이 유일한 안전한 선택임

• setproctitle이 특정 코드베이스에서 작동하지 않았던 경험을 상기시킴

  • numpy를 임포트한 후 setproctitle이 작동하지 않았고, 이는 numpy 초기화 시 getenv 또는 setenv 호출로 인해 **environ의 주소가 변경되었기 때문임