KSH portability

[Guy Harris]

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