Skip to content

Commit de74451

Browse files
authored
Fix working-with-unsafe.md (#15)
* Obey to translation table * Make letters italic * Translate untranslated comment * Translate untranslated comment * Obey to translation table * Make letters italic * Obey to translation table * Comment out the original English paragraph * Make letters italic * Obey to translation table
1 parent 23648cf commit de74451

File tree

1 file changed

+17
-16
lines changed

1 file changed

+17
-16
lines changed

src/working-with-unsafe.md

Lines changed: 17 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ binary manner. Unfortunately, reality is significantly more complicated than
1010
that. For instance, consider the following toy function:
1111
-->
1212

13-
たいていの場合、危険な Rust を扱うツールは、限定された状況やバイナリでしか使えないようになっています。
13+
たいていの場合、アンセーフな Rust を扱うツールは、限定された状況やバイナリでしか使えないようになっています。
1414
残念なことに、現実はそれよりも極めて複雑です。例えば、以下の簡単な関数を見てみましょう。
1515

1616
```rust
@@ -58,7 +58,7 @@ operations necessarily depends on the state established by otherwise
5858

5959
*安全なコードを変更しただけなのに*、今やこのプログラムは安全ではなくなりました。
6060
これが安全性の本質的な問題です。局所的ではないのです。
61-
危険な操作の健全性は、通常 "安全" な操作によって構築された状態に依存しているのです。
61+
アンセーフな操作の健全性は、通常 "安全" な操作によって構築された状態に依存しているのです。
6262

6363
<!--
6464
Safety is modular in the sense that opting into unsafety doesn't require you
@@ -69,11 +69,11 @@ safety *isn't* modular in the sense that programs are inherently stateful and
6969
your unsafe operations may depend on arbitrary other state.
7070
-->
7171

72-
安全性は、危険な操作をしたからといってあらゆる他の悪い事を考慮する必要はない、という意味ではモジュール化されています。
73-
例えば、スライスに対して未チェックのインデックスアクセスをしても、スライスが null だったらどうしようとか
72+
安全性は、アンセーフな操作をしたからといってあらゆる他の悪い事を考慮する必要はない、という意味ではモジュール化されています。
73+
例えば、スライスに対して未チェックのインデックスアクセスをしても、スライスがヌルだったらどうしようとか
7474
スライスが未初期化のメモリを含んでいるかもといった心配をする必要はありません。基本的には何も変わりません。
75-
しかし、プログラムは本質的にステートフルであり、危険な操作はその他の任意の状態に依存しているかもしれない
76-
という意味で、安全性はモジュール化されてはいないのです
75+
しかし、プログラムは本質的にステートフルであり、アンセーフな操作はその他の任意の状態に依存しているかもしれない
76+
という意味で、安全性はモジュール化*されてはいない*のです
7777

7878

7979
<!--
@@ -99,7 +99,7 @@ pub struct Vec<T> {
9999
impl<T> Vec<T> {
100100
pub fn push(&mut self, elem: T) {
101101
if self.len == self.cap {
102-
// not important for this example
102+
// この例では重要ではありません。
103103
self.reallocate();
104104
}
105105
unsafe {
@@ -125,7 +125,7 @@ adding the following method:
125125

126126
```rust,ignore
127127
fn make_room(&mut self) {
128-
// grow the capacity
128+
// キャパシティを大きくする
129129
self.cap += 1;
130130
}
131131
```
@@ -149,7 +149,7 @@ module boundary with privacy.
149149
-->
150150

151151
`unsafe` は関数そのものを汚染するだけでなく、*モジュール* 全体を汚染します。
152-
一般的に、危険なコードのスコープを制限する唯一で完全無欠の方法は、モジュール境界での非公開性を利用することです。
152+
一般的に、アンセーフなコードのスコープを制限する唯一で完全無欠の方法は、モジュール境界での非公開性を利用することです。
153153

154154
<!--
155155
However this works *perfectly*. The existence of `make_room` is *not* a
@@ -175,21 +175,22 @@ well-behaved in a way that safe code doesn't care about.
175175
-->
176176

177177
このように、複雑な普遍条件に依存した安全な抽象化を提供することは可能なのです。
178-
これは安全な Rust と危険な Rust の関係において決定的に重要です
179-
すでに見たように、危険なコードは *特定* の安全なコードを信頼しなくてはなりませんが、
178+
これは安全な Rust とアンセーフな Rust の関係において*決定的に*重要です
179+
すでに見たように、アンセーフなコードは *特定* の安全なコードを信頼しなくてはなりませんが、
180180
安全なコード *一般* を信頼することはできません。
181-
安全なコードを書くときには気にする必要はないのですが、危険なコードでは、
182-
trait の任意の実装や渡された任意の関数が行儀よく振る舞うことを期待することはできないのです。
183-
181+
安全なコードを書くときには気にする必要はないのですが、アンセーフなコードでは、
182+
トレイトの任意の実装や渡された任意の関数が行儀よく振る舞うことを期待することはできないのです。
184183

184+
<!--
185185
However if unsafe code couldn't prevent client safe code from messing with its
186186
state in arbitrary ways, safety would be a lost cause. Thankfully, it *can*
187187
prevent arbitrary code from messing with critical state due to privacy.
188+
-->
188189

189-
しかし、安全なコードが状態をあらゆる方法でぐちゃぐちゃにすることを、危険なコードが防げないのだとしたら
190+
しかし、安全なコードが状態をあらゆる方法でぐちゃぐちゃにすることを、アンセーフなコードが防げないのだとしたら
190191
安全性とは絵に描いた餅かもしれません。
191192
ありがたいことに、非公開性を利用することで、
192-
任意のコードが重要な状態をめちゃくちゃにしないよう防ぐことができるのです
193+
任意のコードが重要な状態をめちゃくちゃにしないよう防ぐことが*できる*のです
193194

194195
<!--
195196
Safety lives!

0 commit comments

Comments
 (0)