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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5afe598156615c8b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns14feed!worldnet.att.net!attbi_s72.POSTED!53ab2750!not-for-mail From: "Jeffrey R. Carter" Organization: jrcarter at acm dot org User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Get_Line problem (GNAT bug?) References: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> <1165448434.402232.125780@n67g2000cwd.googlegroups.com> <0SIdh.25629$E02.10458@newsb.telia.net> <1165453781.897598.296940@16g2000cwy.googlegroups.com> In-Reply-To: <1165453781.897598.296940@16g2000cwy.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 12.201.97.213 X-Complaints-To: abuse@mchsi.com X-Trace: attbi_s72 1165467640 12.201.97.213 (Thu, 07 Dec 2006 05:00:40 GMT) NNTP-Posting-Date: Thu, 07 Dec 2006 05:00:40 GMT Date: Thu, 07 Dec 2006 05:00:40 GMT Xref: g2news2.google.com comp.lang.ada:7843 Date: 2006-12-07T05:00:40+00:00 List-Id: Adam Beneschan wrote: > > However, I still don't think it should return True here. The concepts > of line, page, and file terminator are logical concepts whose actual > representation is defined by the implementation (A.10(7-8)); it's not > correct to simply assume that (or or ) is equivalent > to a line terminator in all cases. A.10(7) says that the end of a file > is marked by the combination of a line terminator, a page terminator, > and a file terminator. I would hope that in the above case, the > logical end-of-file is considered to be a line terminator followed by a > page terminator followed by a file terminator; the line terminator and > page terminator here would be implicit, and would not be represented by > any actual bits in the disk file, but would be logically considered to > be present. Thus, after Get_Line reads the first string, "Maciek", the > next things would be a line terminator (represented by the second ) > followed by *another* line terminator (implicit, not represented by > anything in the disk file) followed by a page terminator (also > implicit) followed by a file terminator (also implicit); thus, > End_Of_File would return false. I believe there's a permission somewhere in an AI that any or all of the final line, page, and file terminators may be missing, to handle text files not written by Ada, and many non-Ada programs that write text files will end with a line terminator; Ada is allowed to (and should) interpret that as both an EOL and an EOF, just as it interprets . Things are especially messy when reading standard input, because Text_IO assumes that look ahead is possible, and with standard input, it isn't. So, if a text file (not standard input) contained xyz after a Get_Line you'd have eaten xyz and both End_Of_Line and End_Of_File should return True. However, for standard input, as Kazakov said, End_Of_File doesn't know if this 2nd is the last thing in the "file". So it has to wait for more input to be buffered before it can return. There are three cases: 1. The input is . End_Of_File returns True. 2. The input is . End_Of_File has to wait for more input. 3. The input is anything else. End_Of_File returns False. > Somebody please correct me if I'm wrong. If I'm wrong, though, and the > RM requires the behavior I'm seeing, then the RM doesn't seem to make > sense. It comes from the need to handle files created by Text_IO ( is part of the file terminator) and by non-Ada programs (no file terminator). -- Jeff Carter "People called Romanes, they go the house?" Monty Python's Life of Brian 79