Fil-C의 단순화된 모델

Fil-C를 단순화하면, C/C++ 소스의 포인터를 추적 가능한 메타데이터와 함께 변환하는 시스템으로 볼 수 있다.

각 포인터 지역 변수에는 대응하는 AllocationRecord* 가 붙고, 대입·연산·함수 호출·반환 시 이 메타데이터도 함께 이동한다.

• malloc은 실제 데이터뿐 아니라 visible_bytes, invisible_bytes, AllocationRecord의 3중 구조를 만든다.
• 역참조 시에는 포인터가 가리키는 위치가 할당 범위 안인지, 크기 조건을 만족하는지를 검사한다.
• 포인터를 읽거나 쓸 때는 invisible_bytes에 저장된 대응 메타데이터도 함께 따라가며, 정렬 조건이 맞아야 한다.

free는 데이터 영역과 invisible_bytes를 해제하지만 AllocationRecord 자체는 즉시 지우지 않는다. 이 빈틈은 GC가 메우며, 도달 불가능한 AllocationRecord를 추적해 정리한다.

GC는 추가로 두 가지를 한다.

• length == 0인 레코드는 하나의 canonical AllocationRecord로 수렴시킨다.
• 지역 변수의 주소가 스코프 밖으로 탈출할 수 있으면, 컴파일러가 그 변수를 heap allocation으로 승격시킨다.

memmove는 임의 메모리 안의 포인터를 다루기 때문에 더 까다롭다. 정렬된 8바이트 이동은 invisible_bytes까지 함께 옮기지만, 1바이트 단위 이동 여러 번은 그렇지 않다.

생산용 구현에서 더 복잡해지는 지점은 다음과 같다.

• Threads: GC와 free의 경쟁, 원자적 포인터 연산의 보존
• Function pointers: 실행 코드용 메타데이터와 ABI 검증
• Memory optimization: invisible_bytes 지연 할당, 구조체/메타데이터 병합
• Performance optimization: 안전성 비용을 줄이기 위한 다양한 최적화

이 모델이 유용한 경우는 분명하다.

• 대규모 C/C++ 코드를 memory-safe하게 돌려야 하지만, 당장은 재작성할 수 없을 때
• ASan처럼 메모리 버그를 찾는 용도로 실행하고 싶을 때
• 런타임과 컴파일타임이 같은 언어인 Zig 같은 환경에서 안전한 컴파일타임 평가를 원할 때
• pointer provenance를 구체적으로 이해하고 싶을 때

핵심 메시지는, Fil-C가 단순한 “안전한 C”가 아니라 메타데이터를 동반한 포인터 추적 + GC + ABI 재구성으로 메모리 안전성을 강제하는 시스템이라는 점이다.