Rust 1.36 이전에, 개발자들은 나중에 초기화될 값에 대해 스택 메모리를 할당하기 위해 std::mem::uninitialized에 의존하였습니다. 이 함수는 기본적으로 안전하지 않았기 때문에 랜덤한 비트가 있는 메모리 위치에 유효한 T가 존재한다고 컴파일러에 알렸습니다. 안전성을 요구하는 타입(예: bool, char, 또는 참조)에서는 이로 인해 즉시 정의되지 않은 동작이 발생했으며, 컴파일러는 값이 유효하다는 가정하에 최적화를 수행하였습니다(예: bool이 0 또는 1일 때). RFC 1892는 유효한 T가 아직 포함되지 않은 메모리를 명시적으로 나타내기 위해 **MaybeUninit<T>**를 도입하여 이 안전 문제를 해결했습니다.
핵심 문제는 LLVM이 초기화되지 않은 메모리를 undef 또는 poison으로 취급하는 점과, Rust의 자동 드롭 글루 생성입니다. 컴파일러가 타입 T의 변수가 살아 있다고 생각하면, 파괴자 호출 또는 특수 최적화를 수행할 수 있습니다. 만약 T가 bool이라면 초기화되지 않은 바이트가 2의 값을 가질 수 있으며, 이는 비트 유효성 불변성을 위반합니다. 드롭 검사 또는 구분자 검사를 수행할 때 이를 읽는 것은 정의되지 않은 동작을 구성합니다. 또한, 초기화가 배열의 중간에서 실패하면, 배열 타입에 대한 드롭 글루는 모든 요소를 드롭하려 하며, 초기화되지 않은 스택 바이트를 포인터로 해석하여 사용 후 해제 또는 이중 해제 오류를 발생시킵니다.
**MaybeUninit<T>**는 유효한 T를 포함할 수도 있고 포함하지 않을 수도 있는 타입 안전한 컨테이너 역할을 합니다. 이는 컴파일러가 초기화를 가정하는 것을 방지하여 드롭 글루 생성 및 유효하지 않은 비트 패턴 최적화를 억제합니다. 프로그래머는 일반적으로 별도의 인덱스 또는 불리언 배열을 통해 어떤 인스턴스가 초기화되었는지를 수동으로 추적해야 합니다. 값을 추출하기 위해서는 assume_init, assume_init_ref 또는 std::ptr::read를 사용하지만, 이는 반드시 write 또는 포인터 조작을 통해 유효한 T를 provably 작성한 후에 해야 합니다. 중요한 불변식은 assume_init을 초기화되지 않은 메모리에 대해서는 절대 호출하지 말아야 하며, 부분적으로 초기화된 구조를 포기할 때는 초기화된 요소만 수동으로 드롭해야 한다는 것입니다. 이를 통해 자원 누수를 피할 수 있습니다.
use std::mem::{self, MaybeUninit}; use std::ptr; fn init_array_fallible<T, E, const N: usize>( mut f: impl FnMut(usize) -> Result<T, E>, ) -> Result<[T; N], E> { let mut array: [MaybeUninit<T>; N] = unsafe { MaybeUninit::uninit().assume_init() }; let mut i = 0; while i < N { match f(i) { Ok(val) => { array[i].write(val); i += 1; } Err(e) => { for j in 0..i { unsafe { ptr::drop_in_place(array[j].as_mut_ptr()); } } return Err(e); } } } Ok(unsafe { mem::transmute::<[MaybeUninit<T>; N], [T; N]>(array) }) }
여러분은 힙 할당이 금지되고 지연 시간이 결정적이어야 하는 네트워크 인터페이스 카드용 no_std 커널 드라이버를 개발하고 있습니다. 1024개의 Connection 객체에 대한 고정 크기 테이블을 스택에 할당해야 합니다. 각 Connection 초기화는 NIC 버퍼가 가득 차면 실패할 수 있는 하드웨어 레지스터 쓰기를 포함합니다. 문제는 500번째 연결이 실패할 경우, 이전 499개는 제대로 종료(파일 설명자를 닫고 DMA 매핑을 해제)되고, 나머지 524개는 손대지 않아 초기화되지 않은 메모리에서 발생할 수 있는 정의되지 않은 동작을 피하는 것입니다.
한 가지 가능한 접근 방식은 **Default::default()**를 사용하여 배열을 센티널 값으로 미리 초기화하는 것입니다. 이 경우 Connection이 Default를 구현해야 하며, 기본 연결이 여전히 커널 자원을 획득하기 때문에 명시적으로 해제해야 하므로 문제가 발생합니다. 또한 1024개의 더미 연결을 구성하는 것은 초기화 주기를 낭비하고 드라이버의 엄격한 시간 요구 사항을 위반합니다.
두 번째 전략은 **Vec<Connection>**을 사용하여 with_capacity로 동적 추가 후 고정 배열로 변환하는 것입니다. 사용자 공간 코드에서는 안전하고 관례적입니다. 그러나 Vec는 이 커널 맥락에서 사용 가능한 전역 할당자를 필요로 하며, 커널 공간에서는 수용할 수 없는 패닉 경로 및 메모리 단편화를 유발합니다. 또한 고정 크기 배열로의 변환은 런타임 체크를 요구하여 오류 처리 논리를 복잡하게 만듭니다.
세 번째 접근 방식은 초기화 없이 저장소를 할당하기 위해 **MaybeUninit<[Connection; 1024]>**를 활용하는 것입니다. 성공적으로 초기화된 연결은 MaybeUninit::write를 통해 작성되며, 인덱스 i에서 오류가 발생하면 수동으로 0부터 i-1까지 반복하면서 각 초기화된 슬롯에서 ptr::drop_in_place를 호출한 후 오류를 반환합니다. 성공 시, 전체 배열을 초기화된 타입으로 변환합니다. 이 솔루션을 선택한 이유는 비용이 없는 스택 할당을 제공하고 결정론적인 성능을 보장하며, no_std 제약을 충족하고, 진정으로 초기화된 객체에 대해서만 자원 정리가 발생하도록 하기 때문입니다. 결과적으로 부분 실패 복구 중에 정의되지 않은 동작이 발생하지 않고 일관된 마이크로초 수준의 초기화 지연을 유지하는 강력한 드라이버가 완성되었습니다.
초기화되지 않은 MaybeUninit<T>에서 assume_init을 호출하는 것은, 이후에 그 값을 명시적으로 읽지 않더라도 왜 정의되지 않은 동작이 되는가?
많은 후보자들은 정의되지 않은 동작이 데이터를 실제로 액세스할 때만 발생한다고 생각합니다. 하지만 Rust의 타입 시스템은 assume_init을 호출하는 즉시 컴파일러에 유효한 T가 존재한다고 알립니다. 비트 패턴을 검사하여 열거형 변형이나 유효성을 판단하는 특수 최적화가 있는 타입(예: bool, char, Option<&T>, 또는 NonNull<T>)에서, 메모리가 랜덤한 비트를 가지고 있다면 (예: bool의 경우 0xFF), 이 검사는 LLVM에서 정의되지 않은 동작을 유발합니다( poison 또는 undef를 로드함). 또한 스코프가 끝날 때, 컴파일러는 T에 대해 드롭 글루를 삽입하여 가비지 데이터에 대해 파괴자를 실행하려 하며, 이는 충돌이나 보안 취약점을 유발할 수 있습니다. 따라서 assume_init은 프로그래머가 유효한 초기화를 보증하는 계약이며, 이를 위반하면 컴파일러의 상태가 엉망이 됩니다.
MaybeUninit::write를 사용하는 것과 MaybeUninit::as_mut_ptr()로 반환된 포인터에 대해 std::ptr::write를 사용하는 것의 차이점은 무엇이며 각각은 언제 적절한가?
MaybeUninit::write는 T의 소유권을 가져와 초기화되지 않은 슬롯에 작성하고, 이제 초기화된 데이터에 대한 가변 참조를 반환하는 안전한 메서드입니다. 값이 준비되어 있고 즉각적으로 안전하게 접근하고 싶을 때 선호됩니다. 반대로, std::ptr::write는 기존 값을 읽거나 드롭하지 않고 원시 포인터에 값을 쓰는 unsafe 함수입니다(메모리가 초기화되지 않았기 때문에 이는 매우 중요합니다). **as_mut_ptr()**로 얻은 원시 포인터를 통해 쓰고 금지 검사기를 피하려 하거나, 원시 포인터만 있는 저수준 추상화를 구현할 때 ptr::write를 사용해야 합니다. 주요 차이점은 write는 안전 보장과 수명 추적을 제공하는 반면, ptr::write는 대상이 유효하고 올바르게 정렬되어 있으며 초기화되지 않았는지를 수동으로 확인해야 하며, 그렇지 않으면 별칭 위반이나 조기에 드롭할 수 있습니다.
어떻게 하면 MaybeUninit<T>의 부분적으로 초기화된 배열을 올바르게 드롭하고 자원을 누수시키거나 정의되지 않은 동작을 유발하지 않도록 하며, 작업의 순서가 중요한 이유는 무엇인가?
초기화가 인덱스 i에서 실패하면, 오직 0..i의 요소만 드롭해야 합니다. 올바른 절차는 0부터 i-1까지 반복하며 **std::ptr::drop_in_place(array[j].as_mut_ptr())**를 호출하는 것입니다. 이는 MaybeUninit 래퍼에서 값을 이동하지 않고 T의 파괴자를 실행합니다(이는 슬롯을 이동된 상태로 남기게 되지만 여전히 기술적으로 초기화되지 않은 상태입니다). 실패 즉시 این 정리를 수행하는 것이 매우 중요합니다. 그렇지 않으면 오류를 반환하기 전에 깔끔하게 스택 프레임이 정리되지 않습니다. 대신에 배열에 대해 mem::forget을 사용하거나 단순히 반환하면, MaybeUninit 래퍼가 드롭됩니다(이는 널 연산)하지만 내부의 살아 있는 T 인스턴스는 자원을 누수하게 됩니다(예: 파일 핸들이나 힙 메모리). 반대로, 잘못해서 i..N 요소를 드롭하면 유효한 T 인스턴스처럼 가비지 메모리를 취급하여 정의되지 않은 동작을 발생시킵니다.