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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!news.astraweb.com!border5.a.newsrouter.astraweb.com!not-for-mail Date: Wed, 03 Jun 2015 15:24:40 +0930 From: tornenvi User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada.Text_IO.Get_Line issue in windows References: <556be876$0$2775$c3e8da3$76491128@news.astraweb.com> <4c705bb2-6bf8-4ff2-a3a8-651a5ba204fa@googlegroups.com> In-Reply-To: <4c705bb2-6bf8-4ff2-a3a8-651a5ba204fa@googlegroups.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <556e96a4$0$11114$c3e8da3@news.astraweb.com> Organization: Unlimited download news at news.astraweb.com NNTP-Posting-Host: e82c467e.news.astraweb.com X-Trace: DXC=@fSjL=D59W4YCNS1UYSjA1L?0kYOcDh@:W\:Hm@YlDb:0a;J95AcB` On 6/2/2015 12:14 PM, AdaMagica wrote: > As you say, it's a nonregular file. Are you sure the documentation you cite is up to date with your GNAT implementation? Obviously it isn't. > I know by the definition it is a nonregular file however it is a "standard" windows text file. Earlier versions of the compiler did handle it correctly. I just checked the gnat reference manual for gcc 5.1 direct from gnu.org and the documentation is still the same. I also found in a-textio.ads ... ----------------------------------- -- Handling of Format Characters -- ----------------------------------- -- Line marks are represented by the single character ASCII.LF (16#0A#). -- In DOS and similar systems, underlying file translation takes care -- of translating this to and from the standard CR/LF sequences used in -- these operating systems to mark the end of a line. On output there is -- always a line mark at the end of the last line, but on input, this -- line mark can be omitted, and is implied by the end of file. So I believe the intent of the compiler code is as described in the documentation. I did some more digging and it seems that the Get_line function was modified and separated out into its own package (a-tigeli.adb) and the code in this file is different from what it used to be. I believe I have found the problem in that file (a-tigeli.adb) I believe line 193 which is elsif ch /= LM then should read elsif ch /= LM and ch /=EOF then There is even a comment already there saying -- If we get EOF after already reading data, this is an incomplete -- last line, in which case no End_Error should be raised. it just looks like the EOF was not checked for before adding the last character. I will post a bug report to gcc.gnu.org/bugzilla for the FSF compiler. I could not find any way to report a bug to Adacores libre site, is there some where I should report it to? Is there any point? I assume Adacore will be the ones processing the FSF gcc ada bugs anyway.