Newsgroups: comp.unix.internals Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!barmar From: barmar@think.com (Barry Margolin) Subject: Re: Shared libraries are not necessary Message-ID: <1991May21.055103.25680@Think.COM> Keywords: ISC i386 shared libraries Sender: news@Think.COM Reply-To: barmar@think.com Organization: Thinking Machines Corporation, Cambridge MA, USA References: <202@titccy.cc.titech.ac.jp> <1991May17.075555.29787@Think.COM> <211@titccy.cc.titech.ac.jp> Date: Tue, 21 May 91 05:51:03 GMT In article <211@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <1991May17.075555.29787@Think.COM> barmar@think.com writes: >>There are two kinds of software upgrades: those which change the interface >>to the library, and those which only change the implementation. >And, my claim is that the second kind is almost nothing. ... >Most software upgrade is a little more complex than can be processed by >mere library change. How many standard C and Unix library functions have had changes to their interface? I'm sure there have been some changes over the years to the implementations of most of these library routines, but the interfaces have stayed nearly constant. >>I believe they also enhanced >>the /etc/hosts version of the routine to return multiple addresses (our >>/etc/hosts file has several host names with multiple addresses). > >You believe what? No. They didn't do so. Thank you for correcting me. >You should not have said what you believe. If I shouldn't say what I believe, what should I say? Everything else is things that I don't believe, and saying them would be lying. > Instead, see >lib/libc/net/hosttable/gethostnamadr.c of 4.3BSD source. There is only >one IP address entry provided for gethostbyname(). I think I may have been confusing the /etc/hosts version with Sun's YP version. We don't use the DNS version of gethostbyname(), but I've been told that our Suns will use both addresses. >As you don't know enough about host name look up and accompanied complexities >of its management, don't say: > >>Note that an upgrade to use the DNS didn't *have* to include support for >>multiple addresses. > >unless you want to be dishonest. What I meant was just as the /etc/hosts version ignores multiple addresses, the designers of the DNS version could have decided to return only one address, in order to leave the interface the same. Note that the predecessor to the Domain system, the standard HOSTS.TXT file, supported multiple host addresses; it's not new to the DNS, except in the BSD implementation. The original gethostbyname() designers clearly screwed up when they had it only return one address. >>In Multics, library design guidelines also make the first kind easy. Most >>library routines with non-trivial parameters take most of the parameters as >>a pointer to a structure. By convention, the first member of the structure >>is a version number or version string > >The only parameter for gethostbyname() is, trivially, a string. If the structure to be filled in were an in-out parameter, as we generally did in Multics, then the version number could be put there. For library routines that allocate their output structure we would pass the expected version as a separate parameter. The Multics calling sequence also includes the number of arguments, and often includes the argument types (whenever the function is "varargs" or any of the arguments has variable length), so a function could look at the number and types of arguments and infer the version of the caller. No, it's not easy to retrofit these calling conventions onto an established system. These problems are, in my opinion, a legacy of Unix's simplistic original design. On Multics, dynamic linking is used extensively, with many users having personal versions of various library routines, and there were few problems from these interface enhancements. It just requires reasonable system design. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar