chibicc나 slimcc 같은 데에 invisicaps를 붙여보는 건 꽤 재밌는 실험이 될 것 같음
참조 카운팅이나 invisible capability system 변형도 시험해볼 여지가 있고, 약간의 간접 참조 비용 대신 메모리를 아낄 수도 있겠다는 생각임
나는 filc-bazel-template을 만들어서 Bazel target으로 묶어뒀음
이 둘을 함께 써서 hermetic builds를 만들고 싶은 사람에게 도움이 되길 바라는 마음임
나는 이 문장의 뜻을 잘 모르겠음 Upon freeing an unreachable AllocationRecord, call filc_free on it.
내가 보기엔 의도한 말은, 도달 불가능한 AR을 해제하기 전에 visible_bytes와 invisible_bytes 필드가 가리키는 메모리부터 해제하라는 뜻 같음
나는 Fil-C가 지금까지 본 프로젝트 중 가장 저평가된 편이라고 느낌
안전성을 위해 “rewrite it in Rust” 하자는 말보다, 기존 C 프로그램을 완전히 메모리 안전하게 컴파일할 수 있다는 점이 더 흥미롭게 보임
내가 보기엔 몇 가지를 같이 봐야 함
첫째, Fil-C는 더 느리고 더 큼. 그게 괜찮았다면 지난 10년 동안 굳이 Rust보다 Java나 C#로 먼저 갔어야 했다는 말도 가능함
둘째, 여전히 C를 쓰는 셈임. 기존 코드 유지보수엔 괜찮지만 새 코드를 많이 쓴다면 나는 Rust가 훨씬 쾌적하다고 느낌
셋째, Fil-C는 런타임 안전성이고, Rust는 일부를 컴파일 타임에 표현할 수 있음. 더 나아가 WUFFS 같은 언어는 런타임 체크 없이도 컴파일 단계에서 안전성을 증명하려고 하므로, 코드가 논리적으로 틀릴 수는 있어도 크래시나 임의 코드 실행은 막는 방향이라는 점이 다름
내가 보는 Fil-C의 핵심 한계는 runtime memory safety라는 점임
여전히 메모리 안전하지 않은 코드를 쓸 수 있고, 이제는 그 결과가 취약점 대신 확실한 크래시가 된다는 의미에 가까움
신뢰할 수 없는 입력을 받는 웹 API 같은 걸 만든다면, 이런 문제는 결국 denial-of-service로 이어질 수 있어서 낫긴 해도 충분히 좋다고 보긴 어려움
Fil-C 작업 자체를 깎아내리려는 건 아니고, 런타임 접근에는 분명한 한계가 있다고 봄
관심 가져줘서 고마움
다만 공정하게 말하면 Fil-C는 Rust보다 꽤 느리고, 메모리도 더 많이 씀
반면 Fil-C는 safe dynamic linking을 지원하고, 어떤 면에서는 Rust보다 더 엄격하게 안전하다고도 말할 수 있음
결국 트레이드오프이니 각자 상황에 맞게 선택하면 된다는 생각임
내 느낌엔, C/C++ 프로그래머에게 자기 프로그램에 garbage collector를 붙일 수 있다고 말했을 때 눈이 반짝이는 경우는 드묾
그래서 이 아이디어가 기술적으로 흥미로워도 감성적으로는 쉽게 먹히지 않는 것 같음
내가 보기엔 Fil-C는 data race 상황에서는 메모리 안전하지 않음
capability와 pointer 값이 대입 중에 찢어질 수 있어서, 스레드 인터리빙이 나쁘면 잘못된 포인터로 객체에 접근해 임의 오동작이 날 수 있음
이런 한계 자체는 받아들일 수 있는데, 문제를 지적하는 사람들을 지지자들까지 나서서 강하게 몰아붙이는 분위기는 아쉽게 느껴짐
내가 알기론 그 부분은 atomic ops를 써서 처리하고 있음
안타깝게도 그게 오버헤드의 큰 원인 중 하나이기도 함
내가 보기엔 이건 결국 fat pointers 계열 기법의 또 다른 변형임
이런 방식은 보안 보장이 충분하지 않거나, non-fat ABI boundaries를 넘기 어렵거나, 오버헤드가 크다는 이유로 여러 번 구현됐다가 배제된 적이 많았음
하지만 요즘은 fat pointers를 하드웨어가 직접 지원하는 흐름이 다시 나오고 있어서, 너무 일찍 기각하는 건 아닐 수도 있음
게다가 filc는 단순한 fat pointer만으로 설명되지는 않는다고 봄
이미 여러 플랫폼에서 hardware memory tagging이 제공되고 있다는 점도 같이 봐야 한다고 생각함