🚀 go-pugleaf

In article <1990Sep24.082942.10213@athena.mit.edu> jik@athena.mit.edu
(Jonathan I. Kamens) writes:
>  First of all, I thought all of the sockaddr structures (in 4.3BSD, "all"
>means sockaddr_in and sockaddr_un, unless I've forgotten something :-) are
>padded so that they're the same length.  Is this not correct?

4.3BSD-tahoe also has `sockaddr_xn', which is padded.  However, a
sockaddr_un is 112 bytes, and sockaddr_in and sockaddr_xn are both 16
bytes (and the same size as `sizeof(struct sockaddr)').

>  Second, the documentation in /usr/doc/ps1/07.ipctut and /usr/doc/ps1/08.ipc
>all uses sizeof() on the sockaddr structure to get the third argument to
>bind().  Is that documentation all wrong,

It is now.

>and if so, is it updated in 4.3-Reno?

Not yet (or at least, I have not updated ours).

>And finally, what do you mean when you say that the documentation "says that
>the name length `should' be exactly right"?  I can't find any documentation
>anywhere ....

I guess maybe we never got around to writing it yet. :-)

There was always a sneaky suspicion that a constant (`sizeof(...)' is
always a constant) was not right.  It worked for TCP/IP and for XNS,
but it did not work properly for path names (a kludge---using the
maximum size the current implementation could handle---made it
function).  Now, with ISO variable-length addresses, it also does not
work for TP.

The solution was to discard `backwards compatibility' except where such
was essentially free, i.e., Internet, XNS, and---at least temporarily---
Unix domain sockets.  (`Backwards compatibility means we get to keep
all our old mistakes.')

The iso(4) man page in 4.3-reno hints at the fact that sizeof() will fail
under some circumstances, but is not clear on what is the `right' value
for namelen.  Something should be done about this someday.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris