질문 이력:
RFC 1758 이전에 Rust는 FFI에서 제로 비용 newtype을 위한 메커니즘이 없었습니다. 개발자들은 결정론적 레이아웃을 부과하는 **#[repr(C)]**를 의존했지만, 이는 불필요한 패딩을 초래할 수 있으며, 또는 필드 재배치 및 틈새 활용과 같은 공격적인 컴파일러 최적화를 허용하는 **#[repr(Rust)]**를 사용했습니다. 이는 래퍼 구조체를 통한 타입 안전성을 강제하는 것과 외부 함수 호출을 위한 ABI 안정성을 보장하는 것 간의 근본적인 딜레마를 만들어냈습니다. **#[repr(transparent)]**은 단 하나의 비제로 크기 필드를 포함하는 구조체가 해당 필드와 동일한 메모리 레이아웃, 정렬 및 호출 규약을 갖는다고 약속함으로써 이 긴장을 해결하기 위해 도입되었습니다.
문제:
#[repr(Rust)] newtype이 원시 내부 타입을 기대하는 외부 함수에 참조 또는 값을 전달될 때(예: u32 핸들 등), 컴파일러는 래퍼의 필드를 재배치하거나 틈새 최적화를 적용할 수 있습니다. **#[repr(Rust)]**가 안정성 보장을 제공하지 않기 때문에, 래퍼는 내부 타입과 다른 크기, 비트 패턴 유효성 또는 패딩을 가질 수 있습니다. 이는 외부 C 코드가 잘못 정렬된 메모리를 읽거나, 잘못된 비트 패턴을 유효한 포인터로 해석하거나, 가비지 데이터를 접근하게 되어 즉각적인 정의되지 않은 동작과 치명적인 메모리 손상을 초래할 수 있습니다.
해결책:
**#[repr(transparent)]**는 래퍼와 그 단 하나의 비제로 필드가 동일한 크기, 정렬, 및 ABI를 공유하도록 컴파일러에 지시하여 래퍼를 컴파일 타임 전용 추상화로 만듭니다. 컴파일러는 정확히 하나의 필드가 비제로 크기를 가졌는지 보장합니다 (추가 PhantomData 또는 단위 유형 필드를 허용). 이는 래퍼가 내부 타입으로 안전하게 변환되거나 FFI 경계를 넘어서 직접 전달될 수 있게 하여 변환 오버헤드를 방지하게 합니다, 아래와 같이:
#[repr(transparent)] pub struct SocketFd(i32); extern "C" { fn close_socket(fd: i32); } pub fn close(sock: SocketFd) { // 안전: SocketFd는 i32와 동일한 ABI를 가짐 unsafe { close_socket(sock.0); } }
한 개발자가 Rust 애플리케이션을 Linux 커널 netlink 소켓 API와 통합하여 원시 정수 파일 설명자를 통해 통신을 수행합니다. 소켓 유형이 혼합되는 것을 방지하기 위해 struct NetlinkSocket(i32)를 newtype으로 정의합니다. 처음에는 **#[repr(Rust)]**로 표시한 후, NetlinkSocket에 대한 참조를 extern "C" 콜백에 전달합니다. 로컬 개발 중에는 이 기능이 올바른 것처럼 보이지만, LTO (Link-Time Optimization)를 사용하는 릴리즈 빌드에서, 컴파일러는 NetlinkSocket에 대한 공격적인 틈새 최적화를 적용하여 메모리 표현을 근본적으로 변경합니다. 이후 C 커널 모듈은 손상된 포인터 값을 받게 되어 심각한 커널 패닉이 발생합니다.
세 가지 해결책이 평가되었습니다. 첫째, **#[repr(C)]**를 사용하여 안정적이고 결정론적인 레이아웃을 보장하는 것이 고려되었습니다. 이것은 메모리 안전성을 보장하지만, 유용한 틈새 최적화를 비활성화하고 불필요한 패딩 바이트를 유발하여 구조체 크기를 불필요하게 부풀리고 순수 Rust 내부 사용을 복잡하게 했습니다.
둘째, 모든 FFI 호출 지점에서 내부 필드(socket.0)를 수동으로 역참조하는 시도를 했습니다. 이 접근법은 레이아웃 가정을 피했지만, 매우 오류가 발생하기 쉬운 중복을 초래하였으며, 효과적으로 추상화 장벽을 깨고 raw, 비정형 정수가 코드베이스 전역에 걸쳐 전파되도록 허용했습니다.
셋째, NetlinkSocket에 **#[repr(transparent)]**을 적용했습니다. 이 보장은 i32와의 ABI 동등성을 보장하면서 Rust 내에서의 타입 구분을 유지하게 하여, 수동 언래핑이나 변환 논리 없이 구조체가 C로 매끄럽게 전달될 수 있도록 하였습니다.
엔지니어링 팀은 궁극적으로 **#[repr(transparent)]**을 채택했으며, 이는 커널 패닉을 완전히 제거하면서 제로 비용 추상화를 유지했습니다. 이제 래퍼는 Rust 내에서 엄격한 컴파일 타임 보호 역할을 하며, 전체적으로 C ABI와 호환되도록 남아있습니다.
왜 #[repr(transparent)]는 단 하나의 비제로 필드가 제로 크기 타입이 되는 것을 명시적으로 금지하며, 이 제약이 값을 전달할 때 FFI에서 정의되지 않은 동작을 방지하는가?
**#[repr(transparent)]**는 래퍼가 내부 타입과 ABI가 동일하다고 보장합니다. **제로 크기 타입(ZST)**는 크기 0과 정렬 1을 가집니다. 만약 래퍼가 전적으로 ZST만을 감싸도록 허용된다면, 결과 구조체도 제로 크기가 됩니다. 그러나 C는 제로 크기 타입을 제공하지 않으며, 그 호출 규약은 일반적으로 "값으로 전달" 의미를 위해 최소한 1바이트의 데이터가 존재하기를 기대합니다. 제로 크기 값을 FFI를 통해 값으로 전달하는 것은 정의되지 않은 동작을 구성합니다, C는 제로 크기 값을 표현하거나 적절히 처리할 수 없기 때문입니다. 이 제약은 래퍼가 항상 비제로 크기와 내부 필드와 동일한 정렬을 유지하도록 보장하여 C의 기대에 맞는 잘 정의된 ABI를 보존합니다.
**#[repr(transparent)]는 열거형에 적용될 수 있으며, 판별자의 FFI 경계를 가로지르는 가시성을 규제하는 제약은 무엇인가?
예, **#[repr(transparent)]**는 정확히 하나의 변형을 포함하고 그 변형이 정확히 하나의 비제로 크기 필드를 포함하는 열거형에 적용될 수 있습니다. 열거형은 또한 판별자 타입을 정의하기 위해 명시적인 원시 표현을 지정해야 합니다 (예: #[repr(u8)]). 그러나 **#[repr(transparent)]**는 최종 레이아웃이 비제로 필드와 동일함을 보장하므로, 실제로 판별자가 ABI에서 생략됩니다. 따라서 그러한 열거형을 내부 필드 타입으로서 C에 전달하는 것은 안전하지만, C에서 판별자 값에 접근하거나 해석하려고 하는 것은 정의되지 않은 동작을 초래합니다. 후보들은 종종 판별자가 레이아웃에서 물리적으로 없고, 단지 숨겨지거나 접근할 수 없을 뿐이라는 점을 오해합니다.
#[repr(transparent)] 구조체에 추가 필드로서 **PhantomData<T>의 존재가 변동성과 드롭 체크에 어떤 영향을 미치며 ABI에는 영향을 미치지 않는가?
PhantomData<T>는 #[repr(transparent)] 구조체 내에서 두 번째 필드로 명시적으로 허용됩니다. 왜냐하면 그것은 크기 0과 정렬 1을 가지고 있기 때문입니다. 이 필드는 래퍼의 크기, 정렬, 또는 ABI에 영향을 미치지 않지만 (#[repr(transparent)]가 레이아웃을 위해 단 하나의 비제로 필드만을 고려하기 때문), 컴파일러가 타입 매개변수 T에 대한 구조적 관계를 알리는 데 crucial한 역할을 합니다. 이는 변동성에 영향을 미칩니다: 예를 들어, 구조체 Wrapper<T>(*const T, PhantomData<fn(T)>)는 PhantomData 마커로 인해 T에 대해 반대 방향성을 가집니다. 또한 구조체가 개념적으로 T 타입의 데이터를 소유할 수 있도록 하는 드롭 체크 (dropck) 분석을 가능하게 하여, T가 비-'static 생명 주기를 가질 때 불안정성을 방지합니다. 후보들은 종종 PhantomData가 메모리 레이아웃에 영향을 미친다고 잘못 믿거나 FFI 래퍼의 생명 주기 및 소유권 불변을 유지하는 데 필수적인 역할을 무시합니다.