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,68cd50941308f5a9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!l12g2000cwl.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: End_Of_File but not really Date: 8 Dec 2006 09:02:53 -0800 Organization: http://groups.google.com Message-ID: <1165597373.375204.16280@l12g2000cwl.googlegroups.com> References: <1165514423.562024.70510@j72g2000cwa.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1165597378 27540 127.0.0.1 (8 Dec 2006 17:02:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 8 Dec 2006 17:02:58 +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: l12g2000cwl.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news2.google.com comp.lang.ada:7866 Date: 2006-12-08T09:02:53-08:00 List-Id: Randy Brukardt wrote: > "Adam Beneschan" wrote in message > news:1165514423.562024.70510@j72g2000cwa.googlegroups.com... > ... > > (2) This behavior is what the RM requires. To me, this means the RM is > > broken---it just doesn't make sense to me that End_Of_File would return > > True if there is more information in the file to get with Get_Line > > (even if the information is "the presence of a blank line"). But > > perhaps it's my own understanding that is broken; perhaps my > > understanding of what End_Of_File is supposed to do is wrong, even > > though I think it's what a reasonable person would expect a function > > called "End_Of_File" to do. > > This is exactly the state. It's the way these things were defined in Ada 83, > and required by the ACATS since the very begining. I'd be very surprised if > you found any Ada compiler that doesn't have this behavior (didn't you try > it on your compiler to cross-check)? > As I noted before, there is absoletely no chance that this behavior (or any > behavior of Text_IO) would be changed, because there's no possible way for > such a change to the compatible. If the program "knows" about the "lost" > blank line, it might fail badly if the definition was to be changed. So it's > 23 years too late to fix Text_IO. OK, this is the sort of clarification I was looking for. I was under the impression that, since the definitions of the terminators were left up to the implementation, it would be possible for an implementation to define them in a way so that things would work "correctly" (i.e. in a way that would make sense to me). But I guess that's not possible, or in any case implementations aren't expected to do this. Thanks. > The moral is simply to never use Text_IO.End_of_File, but rather handle > End_Error instead. If you try to use End_of_File, you have the potential of > "losing" the last line of the file, you still can have End_Error raised if > you call Get or Get_Line when there is no character at the end of the > file, your program will run slower, and your program won't be able to read > interactively from the keyboard. It's not worth it, no matter what you think > about using exceptions for non-errors. It might have made sense to provide a version of Get_Line with an "End_Of_File" OUT Boolean parameter; this version would behave exactly like the other Get_Line except that it would set this parameter to True instead of raising End_Error. That would have satisfied people who don't like exceptions, while avoiding the hokey semantics of the End_Of_File function (and not requiring Text_IO to do any lookahead). Of course, anyone can easily write their own version of Get_Line that works like that. I agree that, based on the discussions in this thread, the Text_IO.End_Of_File function should just be avoided. -- Adam