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!postnews.google.com!n67g2000cwd.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: Get_Line problem (GNAT bug?) Date: 6 Dec 2006 15:40:34 -0800 Organization: http://groups.google.com Message-ID: <1165448434.402232.125780@n67g2000cwd.googlegroups.com> References: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1165448440 10104 127.0.0.1 (6 Dec 2006 23:40:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 6 Dec 2006 23:40:40 +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: n67g2000cwd.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news2.google.com comp.lang.ada:7830 Date: 2006-12-06T15:40:34-08:00 List-Id: Dmitry A. Kazakov wrote: > I think this is a correct behavior. Here is my explanation of what's going > on: > > When End_Of_File meets a CR (Ctrl-M) it cannot know if this CR manifests > the end of the current line or both the line end and the file end. This is > because a file can ends with a CR, and this trailing CR is not counted as > an empty line. So eventually End_Of_File should attempt to read the > following character, i.e. block. No, I don't think this makes sense. If a disk file contained the characters M a c i e k at the end of the file, then this should be read in as two lines: one line containing the string "Maciek", and one empty line. You're right that this should not be followed by yet another empty line, but that isn't relevant. 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. (We shouldn't be saying CR in any case; Unix uses LF (Ctrl-J) as the line separator, and Windows uses a CR-LF combination. We really should just be talking about "end-of-line" or EOL without referring to any specific ASCII character.) And, in any case, if somehow "a trailing CR is not counted as an empty line" were true, it would be true regardless of whether the program used End_Of_File to test for end of file, or simply used Get_Line and relied on End_Error being raised. So the behavior would have to be the same in both cases. But that's not what I observed. -- Adam