Unix Programming - sockaddr

Author

sockaddr_un

DINH Viet Hoa

2004-10-23, 5:48 pm

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

William Ahern

2004-10-23, 5:48 pm

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.

David Schwartz

2004-10-23, 5:48 pm

"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

Nils O. Selåsdal

2004-10-24, 2:47 am

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);

James Antill

2004-10-24, 5:49 pm

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/

Andrei Voropaev

2004-10-25, 2:48 am

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_path
+ 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

DINH Viet Hoa

2004-10-25, 7:49 am

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 cool, 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

William Ahern

2004-10-25, 5:52 pm

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_pat
> + 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.

DINH Viet Hoa

2004-10-25, 8:47 pm

William Ahern wrote :

> 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.

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 cool, 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

Barry Margolin

2004-10-25, 8:47 pm

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 ***

Andrei Voropaev

2004-10-26, 2:47 am

On 2004-10-26, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <etPan.417d9683.5c44019f.2c3f@utopia>,
> DINH Viet Hoa <dinh.viet.hoa@free.fr> wrote:
>
>
> 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.

This is true. Looks like the problem might come only on Linux, where the
"hidden" addresses kind of conflict with ANY address. ANY address is
just empty string, but if linux sees that the length of structure goes
beyond that 0, then it assumes that user requests "hidden" address.

Andrei