@@ -10,7 +10,7 @@ binary manner. Unfortunately, reality is significantly more complicated than
10
10
that. For instance, consider the following toy function:
11
11
-->
12
12
13
- たいていの場合、危険な Rust を扱うツールは、限定された状況やバイナリでしか使えないようになっています。
13
+ たいていの場合、アンセーフな Rust を扱うツールは、限定された状況やバイナリでしか使えないようになっています。
14
14
残念なことに、現実はそれよりも極めて複雑です。例えば、以下の簡単な関数を見てみましょう。
15
15
16
16
``` rust
@@ -58,7 +58,7 @@ operations necessarily depends on the state established by otherwise
58
58
59
59
* 安全なコードを変更しただけなのに* 、今やこのプログラムは安全ではなくなりました。
60
60
これが安全性の本質的な問題です。局所的ではないのです。
61
- 危険な操作の健全性は 、通常 "安全" な操作によって構築された状態に依存しているのです。
61
+ アンセーフな操作の健全性は 、通常 "安全" な操作によって構築された状態に依存しているのです。
62
62
63
63
<!--
64
64
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
69
69
your unsafe operations may depend on arbitrary other state.
70
70
-->
71
71
72
- 安全性は、危険な操作をしたからといってあらゆる他の悪い事を考慮する必要はない 、という意味ではモジュール化されています。
73
- 例えば、スライスに対して未チェックのインデックスアクセスをしても、スライスが null だったらどうしようとか 、
72
+ 安全性は、アンセーフな操作をしたからといってあらゆる他の悪い事を考慮する必要はない 、という意味ではモジュール化されています。
73
+ 例えば、スライスに対して未チェックのインデックスアクセスをしても、スライスがヌルだったらどうしようとか 、
74
74
スライスが未初期化のメモリを含んでいるかもといった心配をする必要はありません。基本的には何も変わりません。
75
- しかし、プログラムは本質的にステートフルであり、危険な操作はその他の任意の状態に依存しているかもしれない 、
76
- という意味で、安全性はモジュール化されてはいないのです 。
75
+ しかし、プログラムは本質的にステートフルであり、アンセーフな操作はその他の任意の状態に依存しているかもしれない 、
76
+ という意味で、安全性はモジュール化 * されてはいない * のです 。
77
77
78
78
79
79
<!--
@@ -99,7 +99,7 @@ pub struct Vec<T> {
99
99
impl <T > Vec <T > {
100
100
pub fn push (& mut self , elem : T ) {
101
101
if self . len == self . cap {
102
- // not important for this example
102
+ // この例では重要ではありません。
103
103
self . reallocate ();
104
104
}
105
105
unsafe {
@@ -125,7 +125,7 @@ adding the following method:
125
125
126
126
``` rust,ignore
127
127
fn make_room(&mut self) {
128
- // grow the capacity
128
+ // キャパシティを大きくする
129
129
self.cap += 1;
130
130
}
131
131
```
@@ -149,7 +149,7 @@ module boundary with privacy.
149
149
-->
150
150
151
151
` unsafe ` は関数そのものを汚染するだけでなく、* モジュール* 全体を汚染します。
152
- 一般的に、危険なコードのスコープを制限する唯一で完全無欠の方法は 、モジュール境界での非公開性を利用することです。
152
+ 一般的に、アンセーフなコードのスコープを制限する唯一で完全無欠の方法は 、モジュール境界での非公開性を利用することです。
153
153
154
154
<!--
155
155
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.
175
175
-->
176
176
177
177
このように、複雑な普遍条件に依存した安全な抽象化を提供することは可能なのです。
178
- これは安全な Rust と危険な Rust の関係において決定的に重要です 。
179
- すでに見たように、危険なコードは * 特定* の安全なコードを信頼しなくてはなりませんが、
178
+ これは安全な Rust とアンセーフな Rust の関係において * 決定的に * 重要です 。
179
+ すでに見たように、アンセーフなコードは * 特定* の安全なコードを信頼しなくてはなりませんが、
180
180
安全なコード * 一般* を信頼することはできません。
181
- 安全なコードを書くときには気にする必要はないのですが、危険なコードでは、
182
- trait の任意の実装や渡された任意の関数が行儀よく振る舞うことを期待することはできないのです。
183
-
181
+ 安全なコードを書くときには気にする必要はないのですが、アンセーフなコードでは、
182
+ トレイトの任意の実装や渡された任意の関数が行儀よく振る舞うことを期待することはできないのです。
184
183
184
+ <!--
185
185
However if unsafe code couldn't prevent client safe code from messing with its
186
186
state in arbitrary ways, safety would be a lost cause. Thankfully, it *can*
187
187
prevent arbitrary code from messing with critical state due to privacy.
188
+ -->
188
189
189
- しかし、安全なコードが状態をあらゆる方法でぐちゃぐちゃにすることを、危険なコードが防げないのだとしたら 、
190
+ しかし、安全なコードが状態をあらゆる方法でぐちゃぐちゃにすることを、アンセーフなコードが防げないのだとしたら 、
190
191
安全性とは絵に描いた餅かもしれません。
191
192
ありがたいことに、非公開性を利用することで、
192
- 任意のコードが重要な状態をめちゃくちゃにしないよう防ぐことができるのです 。
193
+ 任意のコードが重要な状態をめちゃくちゃにしないよう防ぐことが * できる * のです 。
193
194
194
195
<!--
195
196
Safety lives!
0 commit comments