From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c64c5909c07a2300 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-09 04:12:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!ppp-2-217.cvx1.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Ada way to read/write to character file Date: Wed, 9 Jan 2002 12:11:04 -0000 Message-ID: References: NNTP-Posting-Host: ppp-2-217.cvx1.telinco.net (212.1.137.217) X-Trace: fu-berlin.de 1010578334 28059235 212.1.137.217 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:18685 Date: 2002-01-09T12:11:04+00:00 List-Id: 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