Fix a crash when 'read -u' is given an invalid fd (#53)

File descriptors that are too far out of range will cause the
read builtin to crash. The following example will generate
two crashes:

$ ksh -c 'read -u 2000000' || ksh -c 'read -u-2000000'

The fix is to error out when the given file descriptor is out
of range. This bugfix is from Tomas Klacko, although it was
modified to use 'sh_iovalidfd' and reject numbers greater
than 'INT_MAX':
https://www.mail-archive.com/ast-developers@lists.research.att.com/msg01912.html
The question about 'shp->fdstatus[-1]' only applies to ksh93v-
(ksh93u+ doesn't have any references to 'shp->fdstatus[-1]').

src/cmd/ksh93/bltins/read.c:
- File descriptors that are out of range should be rejected
  with an error message (like invalid file descriptors that
  are in range). The seemingly redundant check for negative
  numbers is there because out of range negative numbers also
  cause memory faults despite the later 'fd<0' check.

src/cmd/ksh93/tests/io.sh:
- Add three tests for attempting 'read -u' on various invalid
  file descriptor numbers.

src/cmd/ksh93/tests/io.sh

@@ -557,5 +557,18 @@ result=$("$SHELL" -ic 'echo >(true) >/dev/null' 2>&1)
 [[ -z $result ]] || err_exit 'interactive shells print a PID during process substitution' \
 				"(expected '', got $(printf %q "$result"))"
 
+# ======
+# Out of range file descriptors shouldn't cause 'read -u' to segfault
+"$SHELL" -c 'read -u2000000' 2> /dev/null
+[[ $? == 1 ]] || err_exit "Large file descriptors cause 'read -u' to crash"
+
+# Separately test numbers outside of the 32-bit limit as well
+"$SHELL" -c 'read -u2000000000000' 2> /dev/null
+[[ $? == 1 ]] || err_exit "File descriptors larger than the 32-bit limit cause 'read -u' to crash"
+
+# Negative numbers shouldn't segfault either
+"$SHELL" -c 'read -u-2000000' 2> /dev/null
+[[ $? == 1 ]] || err_exit "Negative file descriptors cause 'read -u' to crash"
+
 # ======
 exit $((Errors<125?Errors:125))