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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 07 Dec 2006 18:28:55 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1165514423.562024.70510@j72g2000cwa.googlegroups.com> Subject: Re: End_Of_File but not really Date: Thu, 7 Dec 2006 18:29:52 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-LcL54Rvd4jv1EFSbz2ci8i4PpqtiMYOrnvqxf8pA2YKzqVI92aVFscTtrmEybxsDBa5eaNXRT/G5YmY!2+6R4ojXIYqWauJBwYNzdRvAu118kkDgcv4gFSQpTT7k/68G6nqIcV8U/ZlTtWb675eJkmeXPEo5!NSs8KfzGSNfENA== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:7861 Date: 2006-12-07T18:29:52-06:00 List-Id: "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. 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. Randy.