Message-ID: <2287bb5b.8e4@apollo.uucp>
Date: Tue, 23-Oct-84 12:50:58 EDT
Article-I.D.: apollo.2287bb5b.8e4
Posted: Tue Oct 23 12:50:58 1984
Date-Received: Fri, 26-Oct-84 08:43:24 EDT
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 38



Re:  Character arithmetic done in 16 bits.

    Someone can correct me if I'm wrong.  But it is my impression
    that the specification of C states that characters will always
    be converted to integers when used in expressions.  Which
    is annoying on an 8 bit machine, but standard none-the-less.

My main complaint about Aztec C is from a portability standpoint.
The compiler speed I can cope with (particularly since I started
using my spare 64K as a ram disk), and the execution time is
reasonable, but there are major problems with the I/O other than
just speed; as follows:

Aztec C does not buffer it's keyboard input.  When you're UNIX C
program says "read(0, buffer, bufcnt)" it expects that someone
will have done erase and kill processing first.  Not so in Aztec
C.  The only C routine that does processing is "gets()".  I don't
know about you, but that certainly is not the routine I generally use
when doing UNIX I/O.  Furthermore, it's buffering does not appeared
to be the same as the processing done by the shell.  The shell
looks at the device specification to get the erase and kill characters.
I don't think "gets()" does.

So here goes my question:
    Has anyone implemented a new set of I/O routines that DO do buffered
input?

And, while I'm at it:
    Does anyone have a serial driver (or ANY driver) that works with
the CPS Multifunction Card?  (preferably one that accesses the chip directly,
my batteries keep running down (or else someone is clobbering the state)
so that the default speeds are never right; but anything will do).

                                            Thanks,
                                                Kee Hinckley
                                      ...decvax!wivax!apollo!nazgul