sockaddr_un

Hello,

How do I compute the size of sockaddr_un on POSIX systems ?

The definition is not strict on sockaddr_un :

http://www.opengroup.org/onlinepubs/009695399/

I can use of course sizeof(struct sockaddr_un) but most example
gives :

sizeof(some_item_of_struct_1) + sizeof(some_item_of_struct_2) +
strlen(sun_path)

What should I use ?

NOTE: definition does not say that sun_path is at the end of the
structure.

Thanks,

--
DINH V. Hoa,

"j'ai du boulot je peux pas venir" -- cege

DINH Viet Hoa <dinh.viet.hoa@free.fr> wrote:
>     Hello,
>
> How do I compute the size of sockaddr_un on POSIX systems ?

> The definition is not strict on sockaddr_un :

> http://www.opengroup.org/onlinepubs/009695399/

> I can use of course sizeof(struct sockaddr_un) but most example
> gives :

> sizeof(some_item_of_struct_1) + sizeof(some_item_of_struct_2) +
>   strlen(sun_path)

Um, you can't use strlen() to get the size of sun_path, only the length of
the string in sun_path. And presumably whoever put it there already took
(sizeof sun.sun_path) so they wouldn't overflow the array.

> What should I use ?

struct sockaddr_un *sunp;
struct sockaddr_un sun;

(sizeof *sunp) or (sizeof sun)

> NOTE: definition does not say that sun_path is at the end of the
> structure.

Shouldn't matter, and I'd be interested to hear of any implementation
where it does. AFAIK sun_path should be nul-terminated so it shouldn't
be necessary to 1) assume sun_path is at the end and 2) subtract from
the structure size the bytes not used in sun_path.

"DINH Viet Hoa" <dinh.viet.hoa@free.fr> wrote in message
news:etPan.417a808a.4427da4e.32b2@utopia...

> How do I compute the size of sockaddr_un on POSIX systems ?

What are you planning to do with the size once you compute it?

DS

On Sun, 24 Oct 2004 03:58:45 +0200, DINH Viet Hoa wrote:

> David Schwartz wrote :
> 
>
> I want to use the bind() system call on it.
> Am I wrong by doing this ?
No.
Many systems defines the SUN_LEN(x) macro that computes the size of
the sockaddr_un.

> int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen);

On Sun, 24 Oct 2004 03:58:45 +0200, DINH Viet Hoa wrote:

> David Schwartz wrote :
> 
>
> I want to use the bind() system call on it.
> Am I wrong by doing this ?

See evnt_make_bind_local() in:

http://www.and.org/vstr/examples/evnt.c.html

...you can also see evnt_make_con_local() for the other side.

--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

On 2004-10-23, William Ahern <william@wilbur.25thandClement.com> wrote:
> DINH Viet Hoa <dinh.viet.hoa@free.fr> wrote: 
> 
> 
> 
> 
>
> Um, you can't use strlen() to get the size of sun_path, only the length of
> the string in sun_path. And presumably whoever put it there already took
> (sizeof sun.sun_path) so they wouldn't overflow the array.
> 
>
> struct sockaddr_un *sunp;
> struct sockaddr_un sun;
>
> (sizeof *sunp) or (sizeof sun)
> 
>
> Shouldn't matter, and I'd be interested to hear of any implementation
> where it does. AFAIK sun_path should be nul-terminated so it shouldn't
> be necessary to 1) assume sun_path is at the end and 2) subtract from
> the structure size the bytes not used in sun_path.

Hm. On linux. Read man 7 unix. There it specifies that sun_path is the
last element of the structure. And it is very important, because Linux
allows "hidden" paths for unix socket. Those start with 0. So, in this
case I usually calculate the length of address for using in bind, sendto
etc., using the following formula.

len = (size_t)(((struct sockaddr_un *)0)->sun_path) + 1 + strlen(addr.sun_pa
th
+ 1);

Of course when the path is not "hidden", then SUN_LEN(ptr) can be used.

If you read Stevens, "Unix Network programming", there you also find
exactly the same definition. Which means that this is standart (apart
from hidden addresses). So sun_path must be at the end of structure and
to find out the length of address one can NOT use sizeof. In fact, the
size of sun_path is not defined. So sizeof on different systems might
return different values :) The only thing that is defined is the fact
that sun_path is the last field in the structure.

Andrei

Andrei Voropaev wrote :

> If you read Stevens, "Unix Network programming", there you also find
> exactly the same definition. Which means that this is standart (apart
> from hidden addresses). So sun_path must be at the end of structure and
> to find out the length of address one can NOT use sizeof. In fact, the
> size of sun_path is not defined. So sizeof on different systems might
> return different values :) The only thing that is defined is the fact
> that sun_path is the last field in the structure.

This is valid on most systems but POSIX definition does not give details
about the place of sun_path field in the structure.

--
DINH V. Hoa,

"Et alors, les parents d'Odile ? Ils sont trop , et tout ce qu'ils
veulent, c'est qu'elle sorte en boîte tous le soirs [...]
et ils militent contre les maths à l'école ?" -- Virginie Despentes

In article <2u3oe2F25c2fgU1@uni-berlin.de> you wrote:
> Hm. On linux. Read man 7 unix. There it specifies that sun_path is the
> last element of the structure. And it is very important, because Linux
> allows "hidden" paths for unix socket. Those start with 0. So, in this
> case I usually calculate the length of address for using in bind, sendto
> etc., using the following formula.

> len = (size_t)(((struct sockaddr_un *)0)->sun_path) + 1+ strlen(addr.sun_p
at
> + 1);

> Of course when the path is not "hidden", then SUN_LEN(ptr) can be used.

Hmmmmm. I stand corrected. I never realized that the size we're supposed to
give to bind() and connect() was supposed to be a function of the string
length of .sun_path. I've been simply doing (sizeof sun) this whole time
(Linux and *BSD) and never ran into any problems. Yikes.

William Ahern wrote :

> Hmmmmm. I stand corrected. I never realized that the size we're supposed t
o
> give to bind() and connect() was supposed to be a function of the string
> length of .sun_path. I've been simply doing (sizeof sun) this whole time
> (Linux and *BSD) and never ran into any problems. Yikes.

I think taking the sizeof(sun) is still valid but not optimal.
I think that some structure is copied into the kernel and less we copy,
more performant we get :)

--
DINH V. Hoa,

"Et alors, les parents d'Odile ? Ils sont trop , et tout ce qu'ils
veulent, c'est qu'elle sorte en boîte tous le soirs [...]
et ils militent contre les maths à l'école ?" -- Virginie Despentes

In article <etPan.417d9683.5c44019f.2c3f@utopia>,
DINH Viet Hoa <dinh.viet.hoa@free.fr> wrote:

> William Ahern wrote :
> 
>
> I think taking the sizeof(sun) is still valid but not optimal.
> I think that some structure is copied into the kernel and less we copy,
> more performant we get :)

Since this structure is only used when you call bind(), connect(),
getsockname(), or getpeername(), it's very unlikely that it will be in a
bottleneck path of the code.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***