Re: Ada way to read/write to character file

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

<tmoran@acm.org> wrote in message news:IGN_7.9654$762.80315@rwcrnsc54...

> Given timing, error conditions, dropped lines, and the likelihood
> of non-text data, I wonder how often you would actually want to
> do "sequential text I/O" on an RS232 port.

Timing typically turns out not to be a major problem in most cases. In Ada
95, you can always use an ATC time-out to limit a wait. Typically, in the
case of a dropped line, the user resets (or re-runs) the program. Error
conditions simply cause dropped characters; dropped characters can happen
with files anyway (e.g. the typist mistypes something), and Ada programs can
and should deal with this situation in an appropriate way. In the case of
bidirectional I/O with a device, it will often be possible for the program
to detect a (syntax) error in received data, and remedy the problem by
requesting a resend.

Binary (non-text) data (popping up in amongst text data) is not very likely.
Usually, if you have a character device connected to your port, it will not
send or require binary data without being specifically told to do so. Most
(admittedly not all) character devices will never (need to) send or be sent
binary data. If the implementation (and the underlying OS) can deal with
character I/O of all the characters coded 0 to 255, it may be possible to do
binary I/O this way (albeit a nasty way). Since, in Ada 95, you can obtain
the underlying stream of an open text file, this -- or the direct use of
Ada.Streams.Stream_IO -- could be another (better) way to do serial binary
I/O.

Finally, both MS-DOS and the Unixen have all manner of sequential character
'devices' which are not actually serial communications devices (or devices
at all).

It is true that the Ada.Text_IO interface will sometimes be inadequate for
character device I/O, but only sometimes. Things like line and page numbers
might not work properly or meaningfully (but can generally be ignored
anyway). It might be necessary to do a lot of Flushing (but the equivalent
of this is generally necessary for device I/O anyway). (The lack of a
standard Flush was an annoying problem in Ada 83.)

> There's also the question of where do you specify parity & baud rate.

In the 'Form' parameter of the 'Open' procedure, if necessary. An
alternative can be an environment variable, or a system program/function
invoked before the Ada program.

> It's not hard to write a package to do buffered input and output,
> though it varies quite a lot across OSes.

Buffered input and output is usually required in the implementation of
Ada.Text_IO anyway, for ordinary files as well as devices. Thus it makes
sense for the device I/O to be implemented in the same place as the file
I/O, so that the buffering part (at the least) can be shared.

> It may also be that the compiler vendor has supplied one solution.

But this will be non-standard. The whole question was of having a standard
way of doing it.

--
Best wishes,
Nick Roberts