Date: Mon, 28 Aug 2000 17:48:15 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Ed Alley <alley1@llnl.gov> Cc: freebsd-questions@FreeBSD.ORG, ben@FreeBSD.ORG Subject: Re: struct sockaddr_un questions Message-ID: <20000828174815.M18862@fw.wintelcom.net> In-Reply-To: <Pine.LNX.3.93.1000828172753.8641A-100000@jordan.llnl.gov>; from alley1@llnl.gov on Mon, Aug 28, 2000 at 05:32:46PM -0700 References: <Pine.LNX.3.93.1000828172753.8641A-100000@jordan.llnl.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
* Ed Alley <alley1@llnl.gov> [000828 17:33] wrote:
>
> 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?
Ok, I don't know what I thinking here, but the kernel routine that
brings the sockaddr in from userland looks like this:
int
getsockaddr(namp, uaddr, len)
struct sockaddr **namp;
caddr_t uaddr;
size_t len;
{
struct sockaddr *sa;
int error;
if (len > SOCK_MAXADDRLEN)
return ENAMETOOLONG;
MALLOC(sa, struct sockaddr *, len, M_SONAME, M_WAITOK);
error = copyin(uaddr, sa, len);
if (error) {
FREE(sa, M_SONAME);
} else {
#if defined(COMPAT_OLDSOCK) && BYTE_ORDER != BIG_ENDIAN
if (sa->sa_family == 0 && sa->sa_len < AF_MAX)
sa->sa_family = sa->sa_len;
#endif
sa->sa_len = len;
*namp = sa;
}
return error;
}
So basically, the kernel fills in the length in the sockaddr_un,
I don't know why I told you you had to fill it in, sorry.
As far as the length passed to bind, you can just pass the sizeof(sockaddr_un)
to it and it should work fine, in fact that's what my code over here
does.
If you _really_ wanted to save kernel space you could use this macro
(from unp_bind() in kern/uipc_usrreq:
#define offsetof(s, e) ((char *)&((s *)0)->e - (char *)((s *)0))
so what one would do is this:
len = strlen(path) + 1 + offsetof(struct sockaddr_un, sun_path);
Sorry for the initial misinformation, it was an honest mistake.
> 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?
That's what it seems to be for as the kernel actually ignores what's
in it, and uses the third parameter to bind as the length.
> 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.
Hrm, I don't think there's anything here that looks like a flame at
all, thanks for the questions, it gave me something new to checkout.
best of luck,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
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?20000828174815.M18862>