Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!lll-lcc!unisoft!hoptoad!gnu From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.sources.d Subject: Re: Standard for file transmission Message-ID: <4579@hoptoad.uucp> Date: 13 May 88 09:29:19 GMT References: <292@cullsj.UUCP> <537@sol.warwick.ac.uk> <4521@hoptoad.uucp> <2989@bsu-cs.UUCP> Organization: Grasshopper Group in San Francisco Lines: 63 dhesi@bsu-cs.UUCP (Rahul Dhesi) wrote: > If somebody posts source that is compilable > only by the Datalight C compiler, or by MIX C, or by Microsoft Pascal... > ...having Turbo C and > Turbo Pascal would likely mean an investment of a few days or weeks (or > months) making that source work. This is curious. If someone posts a binary, getting it to work on another compilation system would likely mean an investment of weeks or months (or years) -- it's called "rewriting from scratch". This does not seem to bother Rahul; it only bothers him that IBM PC users might have to think rather than just uudecoding and executing. If somebody posts sources that are only compileable on one system (or, bog help us, on one C compiler on one system) then they do not know how to write a portable program. Should we not take their sources, port them to our systems if we want to run them, and send back or post the fixes? This is how I learned to write portable C code -- from seeing how portability problems had come about (in my code and in others' code, on the net) and noticing how talented people had fixed them. I asked a bunch of friends who work on IBM PC's why there are so many programs in the micro world that only compile on certain C compilers. This problem has been faced and solved 10 years ago in the mini world, and the techniques are well known (#ifdef's, declaring "short" or "long" rather than "int", relying on standard library routines rather than system calls, passing the program to a few friends who have different compilers/systems for testing before you post it, etc). Nobody had a decent answer. I'm forced to assume that most of these authors do not know how to write or manage software. The solution to this problem is not to distribute their programs in binary. The solution is to distribute in source, fix it, and thereby teach people a little bit more than they knew about building reliable software. > Users > buy their own [compilers], and they are seldom compatible with each other. Sun's C compiler is not completely compatible with Amdahl's, DEC's, and GNU's. But we know ways to write code that runs under all of them. While the compiler writers could help a bit more, the real problem is the users. > But there will always be many things that will not be efficiently > doable in portable C. High-performance graphics are one glaring > example. Funny, the entire Sun graphics library is written in portable C. All the parts I've seen are in C, and it runs on 680x0, Sparc, and 386. A few months ago we ported it (the parts used in NeWS) to the Mac-II with few problems. Again, while there is always a bit to be squeezed out with assembler, mostly the problem is people who don't know how to write fast code. Let's see their sources, speed them up, and send 'em back. Also give them a copy of Jon Bentley's "Writing Efficient Programs" book. > Finally consider that not all users are, or want to be, programmers. But they come running to the programmers when their binary fails. They had better have sources around if they expect their guru to be able to help them! -- John Gilmore {sun,pacbell,uunet,pyramid,ihnp4}!hoptoad!gnu gnu@toad.com "Use the Source, Luke...."