KSH portability

[Guy Harris]

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

People often toss portability in favor of "performance" when they really don't
gain much performance by doing so.  I have yet to see any evidence that on a
modern machine, at least, the SIGSEGV trick for growing a process's data space
on demand buys you anything.  (I tried

	echo `cat *.c`

in the Bourne shell source directory, both with the vanilla S5R2 Bourne shell
and one modified to explicity test whether the data segment had to be grown, on
a 3B2/400; the performance was the same for both shells.)

Given that I have worked on a variety of machines, with different standard I/O
implementations, different byte orders, different sizes for pointers and
integers, different levels of support for catching SIGSEGV and returning from
the signal handler, etc., *I'd* gladly give up a bit of performance to gain
portability.  You can't make "ksh" users very happy if "ksh" doesn't work at
all....