Unsafe Rust

이 퀘스트의 모든 게 safe Rust 였어 — borrow checker 가 네 코드를 건전하다고 증명하는. unsafe 는 비상구야: 컴파일러가 검증 못 하는 보장을 네가 책임지는 작고 명시적인 문.

unsafe 가 실제로 끄는 것

흔한 미신: unsafe 가 borrow checker 를 끈다. 안 꺼. 정확히 다섯 추가 능력을 켜 — raw 포인터 deref, unsafe 함수 호출, mutable static 접근/수정, unsafe trait 구현, union 필드 접근. 그 외 전부 — 소유권, 빌림, lifetime — 는 unsafe 블록 안에서도 여전히 적용돼. 좁은 예외지 무법지대가 아니야.

증명을 네가 떠맡아

unsafe 안에선 컴파일러가 보통 증명하는 걸 네가 보장해: raw 포인터가 유효하다, 데이터 레이스가 없다, 불변식이 성립한다. 컴파일러가 너를 믿어. 그래서 unsafe 블록은 작게 유지하고 정밀 검토돼 — 하나하나가 버그가 다시 가능해지는 자리니, 작고 명백하게 둬.

unsafe 를 safe 추상화로 감싸. 관용구는 작은 unsafe 코어를 safe 공개 API 뒤에 둬서, 호출자가 unsafe 를 직접 안 건드리게. Vec, Rc, std 상당수가 정확히 이거야: 조심스럽게 감사된 unsafe 내부가 100% safe 인터페이스를 노출. 위험을 국소화하고, 한 번 증명하고, 위쪽 모두가 safe 야.

실제로 필요할 때

대부분 Rust 프로그래머는 unsafe 를 거의 또는 아예 안 써. C 라이브러리 호출 (FFI, 다음 레슨), borrow checker 가 표현 못 하는 자료구조 짓기, 특정 하드웨어나 성능 필요에 손 뻗어. 규칙: 구체적 이유가 생기기 전엔 safe Rust 에 머물고, unsafe 로 가야 하면 나머지 프로그램이 safe 하게 감싸.

Code

unsafe 가 raw-포인터 deref 를 켜, 여기선 그뿐·rust

fn main() {
    let mut num = 5;

    // raw 포인터 만들기는 safe; DEREF 는 unsafe 필요
    let r1 = &num as *const i32;
    let r2 = &mut num as *mut i32;

    unsafe {
        // unsafe 안에선 네가 이 포인터들이 유효하다고 보장
        println!("r1 points at {}", *r1);
        *r2 = 10;
    }
    println!("num is now {num}"); // 10

    // 소유권이랑 빌림은 여전히 적용 — unsafe 는 특정 능력 다섯 개만
    // 켜지, checker 전체가 아니야.
}

Exercise

가변 변수를 만들고, 그걸로 *const 랑 *mut raw 포인터를 잡고, unsafe 블록 안에서 하나로 읽고 다른 걸로 써. 그다음 한 문장으로, 컴파일러가 보통 증명했을 어떤 보장을 정확히 네가 책임졌는지 말해.

Hint

raw 포인터가 유효하고 살아있는 메모리를 가리키고 읽기/쓰기가 aliasing 을 위반 안 한다는 걸 보장했어. 컴파일러가 raw 포인터엔 그걸 증명 못 하니 unsafe 가 너한테 주장하게 해 — 그런 블록을 작게 둬서 주장을 눈으로 검증하기 쉽게.

unsafe 가 실제로 끄는 것

증명을 네가 떠맡아

실제로 필요할 때

Code

External links

Exercise

Progress

댓글 0