Xref: utzoo comp.unix.questions:6962 comp.unix.wizards:8384
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!lvc
From: lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: KSH portability
Summary: to lint or not to lint
Message-ID: <13059@tut.cis.ohio-state.edu>
Date: 11 May 88 21:01:36 GMT
References: <295@cmtl01.UUCP> <12142@tut.cis.ohio-state.edu> <631@vsi.UUCP> <52399@sun.uucp>
Organization: Ohio State Computer & Info Science
Lines: 24


Guy Harris writes:
>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.

Okay, if there is another ksh release and if I get to beta test it,
I will lint the code and fix as many of the bugs as I can.

>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.

I think Korn placed a big emphasis on ksh's performance.  I would gladly
give up a bit of portability to gain performance,  Korn may feel the same.
I would rather have portability and high performance but I'll give up
portability if that was necessary.  To me, it is more important to make ksh
users happy than ksh hackers.
-- 
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)