읽기 쉬운 C가 장점이라면서 return uu____0; 같은 코드를 생성한다면, 휴리스틱을 조금만 더 보태 변수명을 return_value 정도로 지을 수는 없을까?
AeneasVerif와 Jonathan Protzenko의 다른 프로젝트들도 적극 추천함. Scylla는 Eurydice와 일종의 쌍대 관계에 있고, Charon과 Aeneas라는 프로젝트도 있음. Microsoft와 Google의 암호 라이브러리에 Eurydice가 생성한 코드를 통합하는 작업이 진행 중이라는 점도 무척 멋짐. 이 글은 Eurydice 입문 자료로도 훌륭함. https://jonathan.protzenko.fr/2025/10/28/eurydice.html.
읽기 쉬운 C를 생성한다면, Rust 컴파일러를 소스부터 완전히 부트스트랩하는 데 아주 좋을 듯함.
부트스트랩에 쓰려면 왜 코드가 읽기 쉬워야 하는지 궁금함.
컴파일 시점뿐 아니라 실행 시점의 안전성을 높여 주는 Rust 고유 기능도 더 다뤘으면 함. 중간 표현(IR) 단계에서는 이미 똑같겠지만, 경계 검사 같은 기능이 다시 C 코드로 어떻게 표현되는지 보고 싶음.
그런 검사도 처리되는 것으로 봄. 원본 소스에 명시했든 Rust의 의미론에 따라 암묵적으로 들어갔든, Rust가 추가하는 검사는 IR에 존재하며 생성된 C 코드에도 반영됨.
Eurydice의 이상적인 출력은 Rust와 정확히 같은 의미론과 안전성을 갖는 코드임. Rust 컴파일러를 지원하지 않는 플랫폼에서도 Rust로 작성한 코드를 쓰려는 용도인 만큼, 이는 매우 중요한 목표이기도 함.
“타입만 다른 함수 구현이 여러 개 생길 수 있으며, C에서는 매크로나 void * 인자를 쓰는 편이 더 관용적”이라는 설명에서 관용적이라는 표현은 우스운 동어반복처럼 느껴짐. 언어를 논할 때 이런 표현은 그만 썼으면 함.
진지하게 작성한 코드 중 비관용적이라고 할 만한 것은 컴파일러나 인터프리터가 이해하지 못하는 코드뿐이라고 봄. 특정 스타일의 보편적 우월성을 내세우는 것은 피상적이고 사려 깊지 못함. 의도적인 난독화는 별개의 문제임.
‘관용적’을 ‘규범적’으로 바꾸면 됨. 컴퓨터 분야에서는 단어의 의미를 어설프게 이해한 채 이름을 붙이곤 하니, 어느 정도는 그러려니 해야 함.
양방향으로 계속 컴파일하면 언젠가 순환 상태에 도달할까, 아니면 코드가 계속 커질까?
D와 C++ 에도 이런 도구가 있으면 도움이 될 듯함.
왜 필요한지 궁금함. C++은 C로 변환하는 전처리기로 출발했고, 요즘 주요 C 컴파일러는 모두 C++로 작성되어 있음. D에도 이미 충분한 백엔드가 있음.