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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news1.google.com!news.germany.com!newsfeed2.scan-plus.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Get_Line problem (GNAT bug?) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: Date: Wed, 6 Dec 2006 22:47:19 +0100 Message-ID: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> NNTP-Posting-Date: 06 Dec 2006 22:47:08 CET NNTP-Posting-Host: 5595ee71.newsspool4.arcor-online.net X-Trace: DXC=gmifV@E5U31TQL:hoD@>T?4IUK[WIO>^kif?8B@2fjlNPj:< X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:7829 Date: 2006-12-06T22:47:08+01:00 List-Id: On Wed, 06 Dec 2006 15:25:31 +0100, Maciej Sobczak wrote: > Consider: > > with Ada.Text_IO; > > procedure Hello is > use Ada.Text_IO; > > Input_Line : String(1..100); > Last_Index : Integer range 0..100; > begin > loop > Put("What's your name? "); > exit when End_Of_File; > Get_Line(Input_Line, Last_Index); > if Last_Index >= Input_Line'First then > Put("Hi, "); > Put(Input_Line(1..Last_Index)); > New_Line; > else > Put("You have funny empty name."); > New_Line; > end if; > end loop; > end Hello; > > (please focus on the Get_Line problem here) > > It should be obvious what the program does, except that the behaviour in > the case of empty input line is a bit strange. > Below, in the right-hand column I describe what keys were pressed: > > $ ./hello > What's your name? Maciek -- M a c i e k ENTER > Hi, Maciek > What's your name? -- ENTER > -- ENTER > You have funny empty name. > What's your name? -- ENTER > You have funny empty name. > What's your name? -- EOF > $ > > As you see, the first ENTER was somehow "swollowed", creating an empty > line in the console (that's the echo of what user typed), but still > blocking in Get_Line. All subsequent ENTERs seem to be handled > correctly, which means that Get_Line returns with Last_Index < > Input_Line'First. > > I was already suggested that it might be a GNAT feature. If yes, it > seems to be persistent, because I see it with two different versions. > > Of course, I expect that empty lines are handled uniformly. > > Any thoughts? 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. This is what happens when you start your program and promptly hit ENTER. When you hit ENTER again, End_Of_File sees, aha, that CR wasn't the end and unblocks. This lets Get_Line to read the *first* CR. The second one remains in the buffer. The next round will block, but this time not on the ENTER you will hit (this would be a third CR), but on the *second* one. So you will observe what appears a "correct" behavior, which in fact is "incorrect", because Get_Line gives you the *previous* empty string. Who cares, all empty strings are empty. (:-)) Now when entered strings aren't empty everything works because End_Of_File reacts on the first character of each line and happily returns. The rules of thumb I suppose I and many other Ada programmers are using: 1. Never ever use End_Of_File with text files; 2. If you yet use End_Of_File then do it for *each* character of the file; 3. As Adam has suggested, End_Error exception is the right design; 4. End_Error is not only cleaner and correct, but also more efficient. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de