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