From cc8bb9cfbb240ce055cebb37a30f16f823fdb2f6 Mon Sep 17 00:00:00 2001
From: nomicon-kr <djwodus18@naver.com>
Date: Sun, 23 Jun 2024 20:59:05 +0900
Subject: [PATCH] Update working-with-unsafe.md

---
 src/working-with-unsafe.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/working-with-unsafe.md b/src/working-with-unsafe.md
index 74cc249..63a6928 100644
--- a/src/working-with-unsafe.md
+++ b/src/working-with-unsafe.md
@@ -53,7 +53,7 @@ pub struct Vec<T> {
 impl<T> Vec<T> {
     pub fn push(&mut self, elem: T) {
         if self.len == self.cap {
-            // not important for this example
+            // 이 예제에는 중요하지 않은 부분입니다
             self.reallocate();
         }
         unsafe {
@@ -79,10 +79,8 @@ fn make_room(&mut self) {
 
 이 코드는 100% 안전한 러스트이지만, 동시에 완전히 불건전합니다. 용량을 변경하는 것은 Vec의 불문율(`cap` 이 Vec의 할당된 용량을 반영한다는 것)을 파괴합니다. 이것은 Vec의 나머지 코드가 방어할 수 있는 것이 아닙니다. Vec은 `cap` 필드를 검증할 방법이 없기 때문에 믿는 *수밖에 없습니다*.
 
+이 `unsafe` 코드는 구조체 필드의 불문율에 의존하기 때문에, 한 함수 전체를 오염시키는 것보다 더한 짓을 합니다: 한 *모듈* 전체를 오염시키죠. 
 
-
-Because it relies on invariants of a struct field, this `unsafe` code
-does more than pollute a whole function: it pollutes a whole *module*.
 Generally, the only bullet-proof way to limit the scope of unsafe code is at the
 module boundary with privacy.