Re: libc0.3-dev: weirdness with sockaddr_un

[Niels Möller]

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.