Robert Millan <[EMAIL PROTECTED]> writes:
> the following code seems to be compliant with the Glibc documentation
> referred to sockaddr_un, as it provides a char* as the second component
> of the struct:
Where do you find the char *? A sockaddr_un contains the family
identifier followed by the filename *in place*. No pointers involved.
When passing a socklen_t and a sockaddr * to system calls[1] like bind
or connect, the sockaddr blob is copied into kernel space, and nothing
else. Storing pointers in the sockaddr would be useless. The glibc
manual I have around "Edition 0.10, last updated 2001-07-06, of `The
GNU C Library Reference Manual', for Version 2.2.x of the GNU C
Library" documents sockaddr_un like this:
The structure for specifying socket names in the local namespace is
defined in the header file `sys/un.h':
- Data Type: struct sockaddr_un
This structure is used to specify local namespace socket
addresses. It has the following members:
`short int sun_family'
This identifies the address family or format of the socket
address. You should store the value `AF_LOCAL' to designate
the local namespace. *Note Socket Addresses::.
`char sun_path[108]'
This is the file name to use.
*Incomplete:* Why is 108 a magic number? RMS suggests making
this a zero-length array and tweaking the following example
to use `alloca' to allocate an appropriate amount of storage
based on the length of the filename.
(AFAIK, the file name need not even be NUL-terminated, all that matters
is the socklen_t you pass around together with the sockaddr *).
> #include <sys/socket.h>
> #include <sys/un.h>
> main ()
> {
> sockaddr_un test = { AF_LOCAL, "" };
> }
What you're trying to do is *not* to initialize a char *, but a
character array. It should be ok to intialize a char array from
a string literal, though, so I don't quite understand the g++ error.
But I don't really use C++ either.
> test.c: In function `int main()':
> test.c:6: invalid conversion from `const char*' to `unsigned char'
/Niels
[1] Ok, on the hurd, they're not really system calls, but the
interface is the same, and we're supposed to be binary compatible
and all.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
