OSDN Git Service

LDP: Replace '引き数' with '引数'
[linuxjm/jm.git] / manual / LDP_man-pages / draft / man7 / unix.7
index 4106e0a..f187d83 100644 (file)
@@ -78,8 +78,8 @@ The \fIsun_family\fP field always contains \fBAF_UNIX\fP.  On Linux, \fIsun_path
 is 108 bytes in size; see also NOTES, below.
 .PP
 様々なシステムコール (例えば \fBbind\fP(2), \fBconnect\fP(2), \fBsendto\fP(2)) は入力として
-\fIsockaddr_un\fP 引数を取る。 他のいくつかのシステムコール (例えば \fBgetsockname\fP(2),
-\fBgetpeername\fP(2), \fBrecvfrom\fP(2), \fBaccept\fP(2)) はこの型の引数を返す。
+\fIsockaddr_un\fP 引数を取る。 他のいくつかのシステムコール (例えば \fBgetsockname\fP(2),
+\fBgetpeername\fP(2), \fBrecvfrom\fP(2), \fBaccept\fP(2)) はこの型の引数を返す。
 .PP
 \fIsockaddr_un\fP 構造体では 3 種類のアドレスが区別される。
 .IP * 3
@@ -114,7 +114,7 @@ is 108 bytes in size; see also NOTES, below.
 .IP *
 終端のヌルバイトを含めたパス名の長さは \fIsun_path\fP の大きさを超えないようにすべきである。
 .IP *
-\fIsockaddr_un\fP 構造体の終わりを示す \fIaddrlen\fP 引数は最低でも以下の値を持つべきである。
+\fIsockaddr_un\fP 構造体の終わりを示す \fIaddrlen\fP 引数は最低でも以下の値を持つべきである。
 .IP
 .nf
     offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
@@ -135,8 +135,8 @@ UNIX ドメインソケットアドレスの扱いが上記のルールに従っ
 .\"
 様々なシステムコール (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2),
 \fBgetpeername\fP(2)) がソケットアドレス構造体を返す。 これらのシステムコールが UNIX ドメインソケットに対して呼ばれた際には、
-これらの呼び出しに渡す \fIaddrlen\fP 引数は上記の説明のように初期化すべきである。
-リターン時には、この引き数にはアドレス構造体の「実際の」サイズが設定される。 呼び出し側ではこの引き数で返された値を確認すべきである。
+これらの呼び出しに渡す \fIaddrlen\fP 引数は上記の説明のように初期化すべきである。
+リターン時には、この引数にはアドレス構造体の「実際の」サイズが設定される。 呼び出し側ではこの引数で返された値を確認すべきである。
 返された値が入力値よりも大きい場合、 \fIsun_path\fP に終端の NULL バイトが存在する保証はない (「バグ」を参照)。
 .SS "Pathname socket ownership and permissions"
 In the Linux implementation, pathname sockets honor the permissions of the
@@ -267,7 +267,7 @@ UNIX ドメインソケットでは、帯域外データ (out\-of\-band data) 
 \fBsend\fP(2) \fBMSG_MORE\fP フラグは UNIX ドメインソケットではサポートされていない。
 .PP
 .\" commit 9f6f9af7694ede6314bed281eec74d588ba9474f
-Linux 3.4 より前では、 \fBrecv\fP(2) の \fIflags\fP 引数での \fBMSG_TRUNC\fP の使用は UNIX
+Linux 3.4 より前では、 \fBrecv\fP(2) の \fIflags\fP 引数での \fBMSG_TRUNC\fP の使用は UNIX
 ドメインソケットではサポートされていなかった。
 .PP
 \fBSO_SNDBUF\fP ソケットオプションは UNIX ドメインソケットで効果を持つが、
@@ -517,11 +517,11 @@ UNIX ドメインのストリームソケットでは、 帯域外データの
 ほとんどの場合、 これは問題にならない。 ソケットアドレスが取得された際、ソケットをバインドしたときに指定したものより 1 バイト長くなるだけである。
 しかしながら、紛らわしい動作が起こる場合が一つある。 ソケットをバインドした際に 108 個の NULL でないバイトを指定した場合、 終端の NULL
 が追加されるとパス名の長さが \fIsizeof(sun_path)\fP を超えてしまう。 結果として、(例えば \fBaccept\fP(2) で)
-ソケットアドレスを取得した際に、 値を取得する呼び出しの入力の \fIaddress\fP 引き数に \fIsizeof(struct
-sockaddr_un)\fP を指定したとすると、 返されるアドレス構造体は \fIsun_path\fP に終端の NULL を「含まない」ことになる。
+ソケットアドレスを取得した際に、 値を取得する呼び出しの入力の \fIaddress\fP 引数に \fIsizeof(struct sockaddr_un)\fP
+を指定したとすると、 返されるアドレス構造体は \fIsun_path\fP に終端の NULL を「含まない」ことになる。
 .PP
 .\" i.e., traditional BSD
-さらに、 いくつかの実装では、ソケットをバインドする際に終端の NULL が必要ではなく (\fIaddrlen\fP 引数を使って \fIsun_path\fP
+さらに、 いくつかの実装では、ソケットをバインドする際に終端の NULL が必要ではなく (\fIaddrlen\fP 引数を使って \fIsun_path\fP
 の長さが判定される)、 このような実装でソケットアドレスを取得する際には、 \fIsun_path\fP に終端の NULL は存在しない。
 .PP
 ソケットアドレスを取得するアプリケーションでは、 \fIsun_path\fP に終端の NULL が存在しないという移植性の問題を、