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: Fri, 08 Dec 2006 17:01:22 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1165514423.562024.70510@j72g2000cwa.googlegroups.com> <1165597373.375204.16280@l12g2000cwl.googlegroups.com> Subject: Re: End_Of_File but not really Date: Fri, 8 Dec 2006 17:02:17 -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-p0p0vkK4TWNjdDWyHF1eBv0NL2bXc92jV8qwRd8oQZ90t/E7kZXAhpEkzz0DnNa8kWo8hjQEcvXjuI5!6lkqHC0j5kIDwKkjXbc38R+ShjBCQT8UXFtRoqq9P19KA9JG7O941h0GJmOut3GubiIaYJlwmw4o!M/yE1/7oRo8xlw== 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:7868 Date: 2006-12-08T17:02:17-06:00 List-Id: "Adam Beneschan" wrote in message news:1165597373.375204.16280@l12g2000cwl.googlegroups.com... > 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. No, it's not possible. That's because of the definition of writing files. Recall that closing a file adds (logical) line and page terminators before the file terminator if they are not present. Let's show these terminators as (the real representation doesn't matter). Now consider the program: Create (File1, ....); Close (File1); File1 will contain just after this program. Now consider the similar program: Create (File2, ...); New_Line (File2); Close (File2); File 2 will *also* contain just . But clearly, when you re-read these two files, you'd expect different behavior. The first should return End_of_File = True immediately and raise End_Error if you call Get_Line, and the second should return End_of_File = False and allow a single call to Get_Line. But these files have the exact same contents! There is no possible way for them to have different behavior, even though they're clearly different from a user perspective. It appears that Ada 83 chose End_of_File = True and a single call to Get_Line to work in order that the most important feature of each of these files works as expected. (That is, if the last line of a file that you write is a blank line, you can read a blank line; and that a Get(char) following End_of_File = False will always work.) But the result of that is that neither file will read quite as expected! IMHO, it would have been better to define End_of_File such that a subsequent Get_Line would always raise End_Error (it does mean that for Get(char)). But such hindsight is 20-20. Since these two files are identical to the language, and certainly the ACATS could check that they're considered identical (it makes similar checks, I don't know if this exact one is made), no amount of implementor tricks can make things work sensibly. In our implementation, the two files would indeed have different contents (the first would be empty and the second would have an explict [or just , depending on the target]}. But that doesn't help, because we have to consider them logically the same, since the language does -- indeed, it makes it more complex than simply writing out all of the markers. (Depending on all of the markers to be present would make Text_IO useless on files written by something other than Ada, which would be unusuable even if it is technically correct.) Randy.