To curse or not to curse

[John E Van Deusen III]

In article <36 at iisat.UUCP> jules at iisat.UUCP (Jules d'Entremont) writes:
>
> ... converting some programs from Turbo Pascal 5.0 to work in  Unix C
> [and] having difficulty translating a Turbo Pascal function (getch ?)
> which reads in a character from the keyboard unechoed, ... without
> waiting for a carriage return. ...  What is the best, most portable
> way to do it?

There are two fundamental differences in the I/O handling of Pascal and
of UNIX/C.  First of all, Pascal does not really have a universal
standard I/O interface.  There have evolved many extensions to the
language, and (getch ?) is one of those.  As of the time I gave up in
disgust, scrapped thousands of lines of Pascal systems code, and started
using C exclusively; that function was not in common use.  If (getch ?)
works like getchar(3S) and returns a new line character to denote the
end of a line, then an emulation should be possible using ioctl(2).

A read(2) in C that has a positive return value provides no information
about the EOF status of the file.  In Pascal the return of the eof() and
eoln() functions must be available immediately after the file is reset
or read.  This is clearly untenable for purposes of terminal I/O,
because it requires prescient knowledge.  The solution that was adopted
is to cheat.  After the reset() of a terminal, the eof() and eoln()
functions return false.  Any read(x_char) that results in an EOF
condition, causes a blank to be assigned to x_char, and then eoln() and
eof() return true.  Because of this, Pascal can not distinguish a single
blank from an empty line or an empty file.  This does, however, enable a
function like (getch ?) to be implemented, since input can be stolen
from the Pascal input file without risking a change in the eof() or
eoln() returns.
--
John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii