Re: Get_Line problem (GNAT bug?)

["Adam Beneschan" <adam@irvine.com>]

Maciej Sobczak wrote:
> Hi,
>
> 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?

It has something to do with the End_Of_File call.  I got the same
behavior that you did, but when I commented out the line "exit when
End_Of_File;" [and used another method to determine when to exit the
loop---specifically, I exited when the input was equal to "quit"], I
did not get that behavior.  Note that when "standard input" is a
terminal or the equivalent, the End_Of_File call has to perform an
input operation because it has to wait for the user to press control-D
(on Unix-like systems) before End_Of_File knows what to return.  It may
be that that isn't being handled quite correctly.

I also found that if I took out "exit when End_Of_File" and added an
exception handler for End_Error, the erroneous behavior didn't occur.

                              -- Adam