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 Path: g2news2.google.com!postnews.google.com!16g2000cwy.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: Get_Line problem (GNAT bug?) Date: 6 Dec 2006 17:09:42 -0800 Organization: http://groups.google.com Message-ID: <1165453781.897598.296940@16g2000cwy.googlegroups.com> References: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> <1165448434.402232.125780@n67g2000cwd.googlegroups.com> <0SIdh.25629$E02.10458@newsb.telia.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1165453787 23436 127.0.0.1 (7 Dec 2006 01:09:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 7 Dec 2006 01:09:47 +0000 (UTC) User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 16g2000cwy.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news2.google.com comp.lang.ada:7834 Date: 2006-12-06T17:09:42-08:00 List-Id: Bj=F6rn Persson wrote: > Adam Beneschan wrote: > > After the > > first Get_Line has consumed the characters M a c i e k , then, when > > End_Of_Line looks ahead and sees that the next character is , it > > should be able to return False immediately without needing to look > > ahead to see whether is immediately followed by EOF. And I don't > > see why this wouldn't apply to an interactive file as well. > > I agree that that's how it should be, but it's not how End_Of_Line is > defined: "Returns True if a file terminator is next, or if the combination > of a line, a page, and a file terminator is next; otherwise returns False= ." I meant to type End_Of_File. But End_Of_File is defined the same way: it returns True if the combination of a line, a page, and a file terminator is next. (A.10.5(25)) 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. This is all implementation-dependent. However, I'd consider that if an implementation would return two strings for Get_Line ("Maciek" and "") and raise End_Error only the third time Get_Line is called, but would return True for End_Of_File after just the *first* Get_Line, then the implementation would be in error since it isn't consistent. You may be able to interpret the RM in a way that would make this permissible, but the unwritten rule is that implementations are supposed to act sensibly, and this would not make sense. (By the way, the behavior that I believe makes no sense is also how GNAT is acting when reading from a file opened with Open, rather than standard input.) 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. -- Adam