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이 제공되고 있다는 점도 같이 봐야 한다고 생각함
Hacker News 의견들
참조 카운팅이나 invisible capability system 변형도 시험해볼 여지가 있고, 약간의 간접 참조 비용 대신 메모리를 아낄 수도 있겠다는 생각임
이 둘을 함께 써서 hermetic builds를 만들고 싶은 사람에게 도움이 되길 바라는 마음임
Upon freeing an unreachable AllocationRecord, call filc_free on it.내가 보기엔 의도한 말은, 도달 불가능한 AR을 해제하기 전에
visible_bytes와invisible_bytes필드가 가리키는 메모리부터 해제하라는 뜻 같음안전성을 위해 “rewrite it in Rust” 하자는 말보다, 기존 C 프로그램을 완전히 메모리 안전하게 컴파일할 수 있다는 점이 더 흥미롭게 보임
첫째, Fil-C는 더 느리고 더 큼. 그게 괜찮았다면 지난 10년 동안 굳이 Rust보다 Java나 C#로 먼저 갔어야 했다는 말도 가능함
둘째, 여전히 C를 쓰는 셈임. 기존 코드 유지보수엔 괜찮지만 새 코드를 많이 쓴다면 나는 Rust가 훨씬 쾌적하다고 느낌
셋째, Fil-C는 런타임 안전성이고, Rust는 일부를 컴파일 타임에 표현할 수 있음. 더 나아가 WUFFS 같은 언어는 런타임 체크 없이도 컴파일 단계에서 안전성을 증명하려고 하므로, 코드가 논리적으로 틀릴 수는 있어도 크래시나 임의 코드 실행은 막는 방향이라는 점이 다름
Fil-Qt: A Qt Base build with Fil-C experience, Linux Sandboxes and Fil-C, Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C, A Note on Fil-C, Notes by djb on using Fil-C, Fil-C: A memory-safe C implementation, Fil's Unbelievable Garbage Collector 같은 스레드들이 있었음
여전히 메모리 안전하지 않은 코드를 쓸 수 있고, 이제는 그 결과가 취약점 대신 확실한 크래시가 된다는 의미에 가까움
신뢰할 수 없는 입력을 받는 웹 API 같은 걸 만든다면, 이런 문제는 결국 denial-of-service로 이어질 수 있어서 낫긴 해도 충분히 좋다고 보긴 어려움
Fil-C 작업 자체를 깎아내리려는 건 아니고, 런타임 접근에는 분명한 한계가 있다고 봄
다만 공정하게 말하면 Fil-C는 Rust보다 꽤 느리고, 메모리도 더 많이 씀
반면 Fil-C는 safe dynamic linking을 지원하고, 어떤 면에서는 Rust보다 더 엄격하게 안전하다고도 말할 수 있음
결국 트레이드오프이니 각자 상황에 맞게 선택하면 된다는 생각임
그래서 이 아이디어가 기술적으로 흥미로워도 감성적으로는 쉽게 먹히지 않는 것 같음
capability와 pointer 값이 대입 중에 찢어질 수 있어서, 스레드 인터리빙이 나쁘면 잘못된 포인터로 객체에 접근해 임의 오동작이 날 수 있음
이런 한계 자체는 받아들일 수 있는데, 문제를 지적하는 사람들을 지지자들까지 나서서 강하게 몰아붙이는 분위기는 아쉽게 느껴짐
안타깝게도 그게 오버헤드의 큰 원인 중 하나이기도 함
이런 방식은 보안 보장이 충분하지 않거나, non-fat ABI boundaries를 넘기 어렵거나, 오버헤드가 크다는 이유로 여러 번 구현됐다가 배제된 적이 많았음
게다가 filc는 단순한 fat pointer만으로 설명되지는 않는다고 봄