메모리 안전성 절대주의자들

unsafe의 존재만으로 Rust를 배제하고 Fil-C만 안전하다고 보는 기준은 실제 소프트웨어의 적용 범위와 기술적 절충을 놓침 Fil-C는 C/C++의 잘못된 메모리 접근을 패닉으로 바꾸지만, ABI 비호환성, 일부 상황에서 수배의 성능 저하, GC 도입이라는 비용이 따름 Android의 약 500만 줄 Rust 코드에서는 출시 전 수정된 잠재적 메모리 안전성 취약점 1건이 발견돼 100만 줄당 0.2건으로 추산됐으며, C/C++의 과거 데이터인 약 1,000건보다 1,000배 이상 낮았음 모든 프로그램에서 문제의 99.9%를 막는 기술과 90%의 프로그램에서 100%를 막는 기술 중 하나만 고를 필요는 없으며, Fil-C의 제약을 수용하기 어려운 소프트웨어에는 Rust 같은 대안이 적합함 메모리 안전성은 성능·ABI·GC·데이터 경쟁 방지를 함께 고려해야 하며, Rust도 불충분하다고 비판한다면 일반 C/C++와 비 Fil-C Zig에는 적어도 같은 기준을 적용해야 함 Rust와 기존 시스템 언어의 책임 모델 비 GC 시스템 프로그래밍 언어의 메모리 안전성 논의는 주로 Rust와 C/C++/Zig의 책임 모델 차이를 중심으로 진행돼 왔음 Rust는 안전할 수도 있는 일부 프로그램까지 거부하는 비용을 감수하면서, 메모리 안전성 문제를 일으킬 수 있는 프로그램의 컴파일을 막으려 함 unsafe는 원시 포인터 역참조 등을 허용해 일부 보장을 우회하는 탈출구임 C 계열 언어는 메모리 안전성 보장을 대부분 프로그래머에게 맡김 C++의 RAII와 스마트 포인터, Zig의 defer처럼 언어별 지원 수준에는 차이가 있지만, 잘못된 메모리 접근 자체를 원칙적으로 차단하지는 않음 Fil-C가 추가한 선택지 Fil-C는 C와 C++ 코드를 메모리 안전하게 실행하는 새로운 접근을 제공함 범위 밖 접근이나 해제 후 사용처럼 잘못된 메모리 접근이 발생하면 패닉을 일으킴 GC와 포인터가 접근할 수 있는 메모리를 추적하는 InvisiCaps를 결합함 Zig에도 Fil-C에서 영감을 받은 새로운 컴파일 모드가 제안됨 인기 C/C++ 프로젝트 일부가 Fil-C로 컴파일한 릴리스를 제공한다면 메모리 안전성 취약점을 줄일 선택지가 늘어날 수 있음 Rust를 안전하지 않다고 보는 기준 Fil-C 개발자는 Twitter에서 unsafe로 일부 보장을 우회할 수 있다는 이유로 Rust를 메모리 안전하지 않은 언어라고 평가해 왔음 Zig 개발자 ...