[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libc0.3-dev: weirdness with sockaddr_un
From: |
Niels Möller |
Subject: |
Re: libc0.3-dev: weirdness with sockaddr_un |
Date: |
03 Apr 2003 14:10:52 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Robert Millan <zeratul2@wanadoo.es> 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.
- libc0.3-dev: weirdness with sockaddr_un, Robert Millan, 2003/04/02
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, GOTO Masanori, 2003/04/03
- Message not available
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, GOTO Masanori, 2003/04/03
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, Stephan Trebels, 2003/04/03
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, Robert Millan, 2003/04/03
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, Jeff Bailey, 2003/04/03
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, Robert Millan, 2003/04/03
- Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un, Niels Möller, 2003/04/03
Re: libc0.3-dev: weirdness with sockaddr_un,
Niels Möller <=