.PP
\fIsun_family\fP フィールドには必ず \fBAF_UNIX\fP が入っている。
-Various systems calls (for example, \fBbind\fP(2), \fBconnect\fP(2), and
-\fBsendto\fP(2)) take a \fIsockaddr_un\fP argument as input. Some other system
-calls (for example, \fBgetsockname\fP(2), \fBgetpeername\fP(2), \fBrecvfrom\fP(2),
-and \fBaccept\fP(2)) return an argument of this type.
+様々なシステムコール (例えば \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 構造体では 3 種類のアドレスが区別される。
.IP * 3
\fIsizeof(sa_family_t)\fP の値と同じだが、 他の実装では \fIsun_path\fP の前に他のフィールドが含まれる場合もある。
そのため、 \fBoffsetof\fP() 式を使う方がより移植性のある方法でアドレス構造体のサイズを知ることができる。)
.IP
-For further details of pathname sockets, see below.
+パス名ソケットの詳細については、後で説明する。
.IP *
.\" There is quite some variation across implementations: FreeBSD
.\" says the length is 16 bytes, HP-UX 11 says it's zero bytes.
より大きく)、 ソケットの名前は \fIsun_path\fP の最初の \fI(addrlen \- sizeof(sa_family_t))\fP
バイトに格納される。 ソケットの抽象名前空間は Linux による拡張であり、移植性はない。
.SS パス名ソケット
-When binding a socket to a pathname, a few rules should be observed for
-maximum portability and ease of coding:
+ソケットにパス名を結びつける際に、 最大限の移植性を持たせ、コーディングを簡単にするためのルールがいくつかある。
.IP * 3
\fIsun_path\fP のパス名はヌル終端すべきである。
.IP *
終端のヌルバイトを含めたパス名の長さは \fIsun_path\fP の大きさを超えないようにすべきである。
.IP *
-The \fIaddrlen\fP argument that describes the enclosing \fIsockaddr_un\fP
-structure should have a value of at least:
+\fIsockaddr_un\fP 構造体の終わりを示す \fIaddrlen\fP 引き数は最低でも以下の値を持つべきである。
.nf
offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
.fi
.IP
-or, more simply, \fIaddrlen\fP can be specified as \fIsizeof(struct
-sockaddr_un)\fP.
+もしくは、もっと簡単には、 \fIaddrlen\fP に \fIsizeof(struct sockaddr_un)\fP を指定することもできる。
.PP
.\" Linux does this, including for the case where the supplied path
.\" is 108 bytes
-There is some variation in how implementations handle UNIX domain socket
-addresses that do not follow the above rules. For example, some (but not
-all) implementations append a null terminator if none is present in the
-supplied \fIsun_path\fP.
+UNIX ドメインソケットアドレスの扱いが上記のルールに従っていない実装もいくつかある。 (全部ではないが) いくつかの実装では、
+\fIsun_path\fP に文字列終端の NULL がなかった場合に終端の NULL が追加される。
.\" HP-UX
.\" Modern BSDs generally have 104, Tru64 and AIX have 104,
.\" Solaris and Irix have 108
-When coding portable applications, keep in mind that some implementations
-have \fIsun_path\fP as short as 92 bytes.
-
-Various system calls (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2),
-\fBgetpeername\fP(2)) return socket address structures. When applied to UNIX
-domain sockets, the value\-result \fIaddrlen\fP argument supplied to the call
-should be initialized as above. Upon return, the argument is set to
-indicate the \fIactual\fP size of the address structure. The caller should
-check the value returned in this argument: if the output value exceeds the
-input value, then there is no guarantee that a null terminator is present in
-\fIsun_path\fP. (See BUGS.)
+移植性があるアプリケーションを作成する際には、 いくつかの実装では \fIsun_path\fP は 92 バイトしかないという点にも留意しておくとよい。
+
+様々なシステムコール (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2),
+\fBgetpeername\fP(2)) がソケットアドレス構造体を返す。 これらのシステムコールが UNIX ドメインソケットに対して呼ばれた際には、
+これらの呼び出しに渡す \fIaddrlen\fP 引き数は上記の説明のように初期化すべきである。
+リターン時には、この引き数にはアドレス構造体の「実際の」サイズが設定される。 呼び出し側ではこの引き数で返された値を確認すべきである。
+返された値が入力値よりも大きい場合、 \fIsun_path\fP に終端の NULL バイトが存在する保証はない (「バグ」を参照)。
.SS ソケットオプション
歴史的な理由により、これらのオプションは たとえ \fBAF_UNIX\fP 固有のオプションであっても \fBSOL_SOCKET\fP 型で指定する。
ソケットファミリーとして \fBSOL_SOCKET\fP を指定すると、 \fBsetsockopt\fP(2) でオプションが設定でき、
UNIX ドメインのストリーム・ソケットでは、 帯域外データの概念はサポートされない。
.SH バグ
.\" The behavior on Solaris is quite similar.
-When binding a socket to an address, Linux is one of the implementations
-that appends a null terminator if none is supplied in \fIsun_path\fP. In most
-cases this is unproblematic: when the socket address is retrieved, it will
-be one byte longer than that supplied when the socket was bound. However,
-there is one case where confusing behavior can result: if 108 non\-null bytes
-are supplied when a socket is bound, then the addition of the null
-terminator takes the length of the pathname beyond \fIsizeof(sun_path)\fP.
-Consequently, when retrieving the socket address (for example, via
-\fBaccept\fP(2)), if the input \fIaddrlen\fP argument for the retrieving call is
-specified as \fIsizeof(struct sockaddr_un)\fP, then the returned address
-structure \fIwon't\fP have a null terminator in \fIsun_path\fP.
+ソケットをアドレスに結びつける際、 Linux は終端の NULL が \fIsun_path\fP になかった場合に追加する実装の一つである。
+ほとんどの場合、 これは問題にならない。 ソケットアドレスが取得された際、ソケットをバインドしたときに指定したものより 1 バイト長くなるだけである。
+しかしながら、紛らわしい動作が起こる場合が一つある。 ソケットをバインドした際に 108 個の NULL でないバイトを指定した場合、 終端の NULL
+が追加されるとパス名の長さが \fIsizeof(sun_path)\fP を超えてしまう。 結果として、(例えば \fBaccept\fP(2) で)
+ソケットアドレスを取得した際に、 値を取得する呼び出しの入力の \fIaddress\fP 引き数に \fIsizeof(struct
+sockaddr_un)\fP を指定したとすると、 返されるアドレス構造体は \fIsun_path\fP に終端の NULL を「含まない」ことになる。
.\" i.e., traditional BSD
-In addition, some implementations don't require a null terminator when
-binding a socket (the \fIaddrlen\fP argument is used to determine the length of
-\fIsun_path\fP) and when the socket address is retrieved on these
-implementations, there is no null terminator in \fIsun_path\fP.
+さらに、 いくつかの実装では、ソケットをバインドする際に終端の NULL が必要ではなく (\fIaddrlen\fP 引き数を使って \fIsun_path\fP
+の長さが判定される)、 このような実装でソケットアドレスを取得する際には、 \fIsun_path\fP に終端の NULL は存在しない。
-Applications that retrieve socket addresses can (portably) code to handle
-the possibility that there is no null terminator in \fIsun_path\fP by
-respecting the fact that the number of valid bytes in the pathname is:
+ソケットアドレスを取得するアプリケーションでは、 \fIsun_path\fP に終端の NULL が存在しないという移植性の問題を、
+パス名の有効なバイト数が以下のようになると事実を考慮することで取り扱うことができる。
.\" The following patch to amend kernel behavior was rejected:
.\" http://thread.gmane.org/gmane.linux.kernel.api/2437
.\" FIXME . Track http://austingroupbugs.net/view.php?id=561
strnlen(addr.sun_path, addrlen \- offsetof(sockaddr_un, sun_path))
-Alternatively, an application can retrieve the socket address by allocating
-a buffer of size \fIsizeof(struct sockaddr_un)+1\fP that is zeroed out before
-the retrieval. The retrieving call can specify \fIaddrlen\fP as
-\fIsizeof(struct sockaddr_un)\fP, and the extra zero byte ensures that there
-will be a null terminator for the string returned in \fIsun_path\fP:
+他の方法としては、 アプリケーションがソケットアドレスを取得する際、 取得の呼び出しを行う前に、 大きさが \fIsizeof(struct
+sockaddr_un)+1\fP のバッファーを割り当てることもできる。 取得の呼び出しでは \fIaddrlen\fP に \fIsizeof(struct
+sockaddr_un)\fP を指定すると、 余分な一つの 0 バイトにより \fIsun_path\fP で返される文字列に終端の NULL
+が含まれることが保証される。
.nf
.in +3
.in
.fi
-This sort of messiness can be avoided if it is guaranteed that the
-applications that \fIcreate\fP pathname sockets follow the rules outlined above
-under \fIPathname sockets\fP.
+アプリケーションが「パス名ソケット」の節で説明したルールにしたがってパス名を「作成」していれば、 このような分かりにくさは避けることができる。
.SH 例
\fBbind\fP(2) 参照。
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-01-04 23:49+0900\n"
-"PO-Revision-Date: 2015-01-05 08:32+0900\n"
+"PO-Revision-Date: 2015-01-09 06:53+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"B<sendto>(2)) take a I<sockaddr_un> argument as input. Some other system "
"calls (for example, B<getsockname>(2), B<getpeername>(2), B<recvfrom>(2), "
"and B<accept>(2)) return an argument of this type."
-msgstr ""
+msgstr "様々なシステムコール (例えば B<bind>(2), B<connect>(2), B<sendto>(2)) は入力として I<sockaddr_un> 引き数を取る。 他のいくつかのシステムコール (例えば B<getsockname>(2), B<getpeername>(2), B<recvfrom>(2), B<accept>(2)) はこの型の引き数を返す。"
#. type: Plain text
#: build/C/man7/unix.7:95
#. type: Plain text
#: build/C/man7/unix.7:120
msgid "For further details of pathname sockets, see below."
-msgstr ""
+msgstr "パス名ソケットの詳細については、後で説明する。"
#. There is quite some variation across implementations: FreeBSD
#. says the length is 16 bytes, HP-UX 11 says it's zero bytes.
msgid ""
"When binding a socket to a pathname, a few rules should be observed for "
"maximum portability and ease of coding:"
-msgstr ""
+msgstr "ソケットにパス名を結びつける際に、 最大限の移植性を持たせ、コーディングを簡単にするためのルールがいくつかある。"
#. type: Plain text
#: build/C/man7/unix.7:166
msgid ""
"The I<addrlen> argument that describes the enclosing I<sockaddr_un> "
"structure should have a value of at least:"
-msgstr ""
+msgstr "I<sockaddr_un> 構造体の終わりを示す I<addrlen> 引き数は最低でも以下の値を持つべきである。"
#. type: Plain text
#: build/C/man7/unix.7:179
msgid ""
"or, more simply, I<addrlen> can be specified as I<sizeof(struct "
"sockaddr_un)>."
-msgstr ""
+msgstr "もしくは、もっと簡単には、 I<addrlen> に I<sizeof(struct sockaddr_un)> を指定することもできる。"
#. Linux does this, including for the case where the supplied path
#. is 108 bytes
"addresses that do not follow the above rules. For example, some (but not "
"all) implementations append a null terminator if none is present in the "
"supplied I<sun_path>."
-msgstr ""
+msgstr "UNIX ドメインソケットアドレスの扱いが上記のルールに従っていない実装もいくつかある。 (全部ではないが) いくつかの実装では、 I<sun_path> に文字列終端の NULL がなかった場合に終端の NULL が追加される。"
#. HP-UX
#. Modern BSDs generally have 104, Tru64 and AIX have 104,
msgid ""
"When coding portable applications, keep in mind that some implementations "
"have I<sun_path> as short as 92 bytes."
-msgstr ""
+msgstr "移植性があるアプリケーションを作成する際には、 いくつかの実装では I<sun_path> は 92 バイトしかないという点にも留意しておくとよい。"
#. type: Plain text
#: build/C/man7/unix.7:220
"check the value returned in this argument: if the output value exceeds the "
"input value, then there is no guarantee that a null terminator is present in "
"I<sun_path>. (See BUGS.)"
-msgstr ""
+msgstr "様々なシステムコール (B<accept>(2), B<recvfrom>(2), B<getsockname>(2), B<getpeername>(2)) がソケットアドレス構造体を返す。 これらのシステムコールが UNIX ドメインソケットに対して呼ばれた際には、 これらの呼び出しに渡す I<addrlen> 引き数は上記の説明のように初期化すべきである。 リターン時には、この引き数にはアドレス構造体の「実際の」サイズが設定される。 呼び出し側ではこの引き数で返された値を確認すべきである。 返された値が入力値よりも大きい場合、 I<sun_path> に終端の NULL バイトが存在する保証はない (「バグ」を参照)。"
#. type: Plain text
#: build/C/man7/unix.7:233
"B<accept>(2)), if the input I<addrlen> argument for the retrieving call is "
"specified as I<sizeof(struct sockaddr_un)>, then the returned address "
"structure I<won't> have a null terminator in I<sun_path>."
-msgstr ""
+msgstr "ソケットをアドレスに結びつける際、 Linux は終端の NULL が I<sun_path> になかった場合に追加する実装の一つである。 ほとんどの場合、 これは問題にならない。 ソケットアドレスが取得された際、ソケットをバインドしたときに指定したものより 1 バイト長くなるだけである。 しかしながら、紛らわしい動作が起こる場合が一つある。 ソケットをバインドした際に 108 個の NULL でないバイトを指定した場合、 終端の NULL が追加されるとパス名の長さが I<sizeof(sun_path)> を超えてしまう。 結果として、(例えば B<accept>(2) で) ソケットアドレスを取得した際に、 値を取得する呼び出しの入力の I<address> 引き数に I<sizeof(struct sockaddr_un)> を指定したとすると、 返されるアドレス構造体は I<sun_path> に終端の NULL を「含まない」ことになる。"
#. i.e., traditional BSD
#. type: Plain text
"binding a socket (the I<addrlen> argument is used to determine the length of "
"I<sun_path>) and when the socket address is retrieved on these "
"implementations, there is no null terminator in I<sun_path>."
-msgstr ""
+msgstr "さらに、 いくつかの実装では、ソケットをバインドする際に終端の NULL が必要ではなく (I<addrlen> 引き数を使って I<sun_path> の長さが判定される)、 このような実装でソケットアドレスを取得する際には、 I<sun_path> に終端の NULL は存在しない。"
#. type: Plain text
#: build/C/man7/unix.7:561
"Applications that retrieve socket addresses can (portably) code to handle "
"the possibility that there is no null terminator in I<sun_path> by "
"respecting the fact that the number of valid bytes in the pathname is:"
-msgstr ""
+msgstr "ソケットアドレスを取得するアプリケーションでは、 I<sun_path> に終端の NULL が存在しないという移植性の問題を、 パス名の有効なバイト数が以下のようになると事実を考慮することで取り扱うことができる。"
#
#. The following patch to amend kernel behavior was rejected:
#: build/C/man7/unix.7:573
#, no-wrap
msgid " strnlen(addr.sun_path, addrlen - offsetof(sockaddr_un, sun_path))\n"
-msgstr ""
+msgstr " strnlen(addr.sun_path, addrlen - offsetof(sockaddr_un, sun_path))\n"
#. type: Plain text
#: build/C/man7/unix.7:585
"the retrieval. The retrieving call can specify I<addrlen> as "
"I<sizeof(struct sockaddr_un)>, and the extra zero byte ensures that there "
"will be a null terminator for the string returned in I<sun_path>:"
-msgstr ""
+msgstr "他の方法としては、 アプリケーションがソケットアドレスを取得する際、 取得の呼び出しを行う前に、 大きさが I<sizeof(struct sockaddr_un)+1> のバッファーを割り当てることもできる。 取得の呼び出しでは I<addrlen> に I<sizeof(struct sockaddr_un)> を指定すると、 余分な一つの 0 バイトにより I<sun_path> で返される文字列に終端の NULL が含まれることが保証される。"
#. type: Plain text
#: build/C/man7/unix.7:589
"This sort of messiness can be avoided if it is guaranteed that the "
"applications that I<create> pathname sockets follow the rules outlined above "
"under I<Pathname sockets>."
-msgstr ""
+msgstr "アプリケーションが「パス名ソケット」の節で説明したルールにしたがってパス名を「作成」していれば、 このような分かりにくさは避けることができる。"
#. type: Plain text
#: build/C/man7/unix.7:611
OSDN Git Service
