Path: utzoo!attcan!uunet!aplcen!haven!ncifcrf!lhc!mimsy!chris From: chris@mimsy.umd.edu (Chris Torek) Newsgroups: comp.unix.programmer Subject: Re: binding sockets Summary: `backwards compatibility means retaining your old mistakes' Message-ID: <26689@mimsy.umd.edu> Date: 24 Sep 90 18:17:05 GMT References: <1990Sep24.082942.10213@athena.mit.edu> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 44 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