Xref: utzoo comp.unix.questions:6909 comp.unix.wizards:8328 Path: utzoo!mnetor!uunet!husc6!mailrus!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: KSH portability Message-ID: <52399@sun.uucp> Date: 7 May 88 21:08:33 GMT References: <295@cmtl01.UUCP> <12142@tut.cis.ohio-state.edu> <631@vsi.UUCP> <12692@tut.cis.ohio-state.edu> Sender: news@sun.uucp Lines: 38 > I had a conversation with Korn about this once. He said that > if he made ksh lint free that it would lose portability! I > was pretty suprised, but I'll believe him. I'm pretty surprised, too, but I'm not sure *I* believe him. The complaints listed (null-pointer arguments not properly cast, functions returning pointers not properly declared, etc.) reduce portability when fixed only if "portability" means "portability to systems with horribly broken C compilers". They *increase* portability to systems with *valid* C implementations where: 1) pointers and "int"s are not the same size 2) null pointers aren't represented by all-zero bit patterns 3) functions returning pointers, and functions returning "int"s, return their results differently There may be cases where making it completely free of "lint" complaints may cause problems; however, all the problems listed above can be fixed without impairing portability, and the first of them, at least, is a *real* problem on *many* implementations. > Back to the stdio hassle with ksh, Korn also told me once that > one of the biggest problems in making sh pportable was that the > stdio *implementations* differed so much. I'm sure he would > have done the "portable thing" if it were possible, but it must > not have been possible. Isn't all the world System V :-) The only way that making something portable is made difficult by differences in *implementations* is if you're depending on particular details of the implementation. If you want to make code portable, you avoid doing that wherever possible; you code to the specification, not the implementation. If you absolutely *must* depend on those details, you had better be prepared to give up portability. Period. (And, frankly, I don't think that Korn had to depend on those details; I redid the Korn shell's use of standard I/O to depend far less on the implementation just so I *could* get it to work on a system where not all "FILE" structures came from a single array.)