Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Aug 2000 17:32:46 -0700 (PDT)
From:      Ed Alley <alley1@llnl.gov>
To:        freebsd-questions@freebsd.org
Cc:        ben@freebsd.org
Subject:   struct sockaddr_un questions
Message-ID:  <Pine.LNX.3.93.1000828172753.8641A-100000@jordan.llnl.gov>

next in thread | raw e-mail | index | archive | help


My questions involve the sockaddr_un structure in FreeBSD: It is
different than most other OSs because of the additional one byte
sun_len entry. I have submitted a question before to FreeBSD-
questions on this issue when I first encountered it. I am porting
my software to FreeBSD from Linux because I have become a FreeBSD
convert; therefore, I am not looking for flames from these questions
but genuine enlightenment.

I have a software application that creates a UNIX domain socket. The
codeing problem has to do with setting up the sockaddr_un structure
to pass to bind. I used an algorithm that I got from Stevens' book:
UNIX Network Programming (1990).

The code goes like this:

	#define PATH "/tmp/my_socket"

	struct sockaddr_un saun;
	int len;		/* length of sockaddr_un */
	int sd;			/* socket descriptor */

		.
		.
		.

	bzero ((char*)&saun, sizeof(saun));
	saun.sun_family = AF_UNIX;
	strcpy(saun.sun_path, PATH);

	len = strlen(saun.sun_path) + sizeof(saun.sun_family);

	unlink (PATH);
	if (bind(sd, (struct sockaddr*) &saun, len) < 0) {
		perror("bind");
		exit(1);
	}

		.
		.
		.

Stevens' makes the comment that bind() needs the length of the
non-zero part of the structure to be passed to it.

  The bug in FreeBSD occurs because the length that is calculated
is two bytes short (one byte for saun.len and one for the null).
The socket gets created but the filename in /tmp that gets
created is "my_socke" not "my_socket". (Why it's not "my_sock"
I think is because you don't really need to count the null
even though the docs say that you do.) Later when I want to
unlink the file I get an error from unlink() saying that the
file, "my_socket", does not exist. The socket file "my_socke"
remains in /tmp. The next time my application trys to bind, it
gets an error to the effect that the address is "already in use",
since it is trying to create "my_socke" that still exists in /tmp.

  Thanks to comments from Ben Smithurst <ben@FreeBSD.org> and
Alfred Perlstein <alfred@FreeBSD.org>, I now know how to fix the
problem in a portable way. Interestingly, one of the responders,
Ben Smithurst, said that he always passes bind() the length
sizeof(saun). (This is not the fix that I am currently using.)
I have tested this and I find that it works on Linux as well as
FreeBSD, with no need to set the saun.sun_len member of the structure
for FreeBSD; that is, saun.sun_len = 0. but the length that is passed
to bind() is sizeof(saun)!  Evidentally, bind() does not use the
saun.sun_len entry. (However, it must look at the null.)

Now for my questions:

  Is there an example in FreeBSD where not setting saun.sun_len
to the correct length is a bug? I am not talking semantics here
where one could say: "If the entry exists then you better fill it."
I mean: Is there an example where a code will crash if that entry
is not filled? If not then, can we always get away with passing
sizeof(saun) to every network routine that wants that socket
structure? Or is passing bind() and other networking routines
sizeof(saun) asking for trouble? If it is not asking for trouble,
then the portability issue is really a non-issue and one wonders:
what is the use of that extra little entry in the sockaddr_un
structure?
	

		Ed Alley
		wea@llnl.gov

P.S.
	There may be places where you want the extra entry in the
	sockaddr_un structure (perhaps in kernel compiles):
	DEC OS defines two sockaddr_un structures. The 4.4BSD form
gets
	used for kernel compiles but can be defined by the user with
the
	_SOCKADDR_LEN user-defined compile parameter. Otherwise, the
	older form without the sun_len entry is the default. Is this
	the answer then: Kernel compiles require the 4.4BSD form?

P.S.S.
	A lot of questions, I know. I like FreeBSD, I'm not trying
	to flame it; I just want to understand it.

		Ed





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.93.1000828172753.8641A-100000>