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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!mit-multics.arpa!Bakin From: Bakin@MIT-MULTICS.ARPA ("David S. Bakin") Newsgroups: net.lang.ada Subject: text_io considered error prone? Message-ID: <850911004642.761469@MIT-MULTICS.ARPA> Date: Tue, 10-Sep-85 20:46:00 EDT Article-I.D.: MIT-MULT.850911004642.761469 Posted: Tue Sep 10 20:46:00 1985 Date-Received: Wed, 11-Sep-85 08:02:02 EDT Sender: daemon@ucbvax.ARPA Organization: The ARPA Internet List-Id: Dear Ada users: I said last week I would mention this week the error-prone construct of text_io.page. Well, I was going to, but after playing around with text_io some more I decided I would just call text_io itself an error-prone construct. My discussion will take the form of a challenge: Using only the I/O described in Chapter 14 of the Ada LRM provide a program which accurately copies an arbitrary text file. (To make it easy, lets assume this arbitrary text file contains only the characters in the 128 element ASCII set.) For extra credit, make sure it is an efficient program. [Now, part of the problem may be that I am using Dec Ada on VMS, which has a record-oriented file system. You may be better off if you are on Unix or MS-DOS and can use sequential I/O instantiated on a character. Still you should try it and make sure sequential I/O works for your system, then try it using text_io alone. Furthermore, I arbitrarily rule that your use of sequential I/O instantiated on a character gets no points for the extra credit: efficiency.] [OK, so lets assume you're using Dec Ada on VMS, or that you're going to use text_io anyway:] Try your program on the following three test cases: 1. A file which ends in a non-blank line. 2. A file which ends in an explicit page-terminator (for Dec Ada, the last line in the file contains one character, an ASCII form feed). 3. A file which ends in a blank line followed by an explicit page- terminator (for Dec Ada, the next to last line in the file has no characters, the last line has only an ASCII form feed). In case you think I'm just causing trouble: I haven't been able to write a program using text_io that correctly handles the above three cases. Sequential_IO instantiated for character doesn't work since for Dec Ada each sequential_io.read reads a record of the file. (A reasonable interpretation of sequential_io.read for a record oriented system.) By the way, because of the way unconstrained records work in Ada you can't instantiate Sequential_IO with an unconstrained type for element_type (like String) and expect to READ a variable length file. [Even if your compiler lets you instantiate Sequential_IO with an unconstrained type for element_type.] (Someone please correct me if I am wrong here.) I ASSERT that Ada I/O should enable you to write a program that can copy any file created with Ada I/O. This assertion is to my mind a reasonable inference from the first two paragraphs of the LRM Introduction where it is asserted that Ada is to be useful for systems programming. OK, I want to write a text editor, or a compiler. (Note that this is a rather weak requirement in real life, since it doesn't even enable you to write a program which can copy any text file on your system (much less binary files), just those which are written by an Ada program.) (Note that this was once a big deal for things like Fortran compilers on IBM mainframes: Could you write a file using Fortran I/O which the compiler could read? For all I know it is still a big deal for things like Fortran compilers.) [Note: If you are using a compiler which doesn't implement Ada I/O as described in the LRM you get 0 points. If you don't have access to any Ada compiler, you may not be able to do this problem at all, but if you do, make sure you are reading the LRM very very carefully.] -- Dave (Bakin @ mit-multics.arpa) [Disclaimer: I work for Alsys, a company deeply involved with Ada, and highly supportive of Ada as a programming language. These opinions are my own, not to be attributed to Alsys or any other person at Alsys. I too am highly supportive of Ada as a programming language. Nevertheless, I don't think its contradictory or wrong to be supportive of the Ada effort and yet believe that it isn't perfect. I also think it useful to discuss problems with the Ada language, in the hope that it can be improved, or that my own misperceptions can be corrected. This disclaimer probably won't appear on future messages I send ... I find these disclaimers obvious and unnecessary in general ... but I thought I should mention it at least once.]