Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!phri!roy From: roy@phri.UUCP Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc Subject: Re: Shared libraries Message-ID: <2906@phri.UUCP> Date: Thu, 24-Sep-87 10:33:17 EDT Article-I.D.: phri.2906 Posted: Thu Sep 24 10:33:17 1987 Date-Received: Sat, 26-Sep-87 13:42:52 EDT References: <2067@sfsup.UUCP> <2903@phri.UUCP> <6461@brl-smoke.ARPA> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 66 Xref: utgpu comp.arch:2196 comp.unix.wizards:4146 comp.os.misc:212 Summary: In which I flame Doug Gwyn for being pompus In <2903@phri.UUCP> I asked: > What do I do on a shared library system when scanf changes out > from under me and breaks my program? In <6461@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) replied: > Obviously, you fix your program. [...] If your code depends on anything > not guaranteed by the interface definition, then you were asking for > trouble all along. I respect Doug Gwyn. He seems to know what he's talking about more than most people, so I don't flame him lightly, but that's the kind of pompus, if-you-can't-do-it-right-don't-do-it-at-all answer that gives computer science a bad name. In the same category as "if it doesn't do X, then it's not C". Yes, it's nice to follow the rules and write code according to the interface definition. But where does that leave the poor schmuck who didn't follow the rules two years ago when he was writing his very grungey but very useful and productive program? In the dirt where he belongs? Sorry, it doesn't work that way in the real world. Maybe we don't have the source any more, or never did. Maybe it's just more trouble than it's worth to fix the code. I don't run a computer science research center, I run a production machine. My users expect to get their work done. If it runs and gives them the right answers, that's more important than following the rules. Many of the people who write production programs here are biologists, not professional programmers. If one of them has a program which has been working for N years and all of a sudden it breaks because I put up a new version of Unix, he doesn't want to know that the new version is better and the reason his program won't run any more is because he didn't follow the interface definition. As far as he's concerned, I broke his program by upgrading the OS and he's pissed at me because he can't get his work done. Guess what? I agree with him. Let me give you an example. One of our big users has a 7000 line Fortran program. The code is 15 years old but it still works, and for what it does, there still isn't anything better. The classic dusty deck. He made a few minor modifications to it involving calling system(3F). Everything worked fine for a year or so running under SunOS-3.0, but then we upgraded to 3.2. Guess what, in 3.2 (and, I understand, in 3.4 as well), the Fortran system() routine is broken. Now it's not even a case of not following the rules, but simply that the new library routine has a bug which the old one didn't. Until we tracked the bug down to the system() call and Sun was able to supply the workaround, our solution was (you guessed it) to continue program development on a 3.0 machine and run the binaries on the 3.2 machines (which had better floating point hardware). It just so happens that Sun was able to supply a workaround which allowed us to link using the new (broken) library, but imagine what would have happened if Sun was using a dynamic library loading scheme and there was no workaround other than linking with the old library. I could have shaved my head and marched up and down the halls chanting "follow the interface definition" till I was blue in the face and it wouldn't have done a damn bit of good. I supposed I could have uninstalled the 3.2 upgrade and refused to pay for it, but that's not what we wanted to do. My background is engineering. In engineering school they teach you to follow the rules and design things according to sound theoretical principles. They also teach you that when push comes to shove, it's sometimes better to break the rules and put a bag on side rather than not have it work at all. Sure, design it so it works like it's supposed to, but just in case, leave the hooks in so you have someplace to hang that bag from if you ever have to. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016