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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fabdf3894cea2f63
X-Google-Attributes: gid103376,public
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Weird get_line()
Date: 1999/03/29
Message-ID: <m3pv5trs32.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 460166255
References: <7dlbot$co$1@nnrp1.dejanews.com> <m3soaptpo9.fsf@mheaney.ni.net>
 <7dmci4$qgd$1@nnrp1.dejanews.com>
NNTP-Posting-Date: Sun, 28 Mar 1999 17:36:37 PDT
Newsgroups: comp.lang.ada
Date: 1999-03-29T00:00:00+00:00
List-Id: <comp.lang.ada>

W1bBle <layabouts@the-giant-sofa.demon.co.uk> writes:

> I've discovered that after issuing a get() and waiting for the user to
> input a number (from a menu choice) what was happening was a /0 was left
> in the input stream.

That's because the user put 2 characters in the stream, one for the menu
item, and another for the <return>.  It's up to you to consume both
characters.

Don't use Get to fetch the menu item.  Use Get_Line:

  declare
    Line : String (1 .. 20);
    Last : Natural;
  begin
    <display list of menu items>

    <<Getting_Selection>> null;

    Put ("Ready: ");
    Get_Line (Line, Last);

    if Last = 0 then

       goto Terminate_Processing;

    elsif Last > 1 then

       Put_Line ("entry too long; try again");
       goto Getting_Selection;

    elsif Line (1) = 'h' then

       <display list of menu items>
       goto Getting_Selection;

    elsif Line (1) = 'x' then

        goto Terminate_Processing;

    elsif Line (1) = 'o' then

        goto Open_File;

    elsif Line (1) = ...

  end;


Using Get_Line will ensure that all characters are consumed, including
the line terminator.

 
> This made the get_line() immediately following it think that you had
> pressed return.  It just processed whatever was left in stdin.

Yes, that is correct, because the <return> is still in the stream.

So just always use Get_Line, and don't bother with Get.

 
> So putting a get_line() command immediately after the get() swallows the
> remaining /0 character and then another get_line() reads the, now
> meaningful, input from stdin.

Yes, that is correct.  The line terminator was not consumed by the Get,
because it only consumed the first character.  

Get didn't see the line terminator, because it came _after_ the
character.

> It appears that both the version of gnat I'm using on Geek Gadgets (on
> an Amiga but also on BeOS AFAIK) and the version running on an SGI
> server at my university share this "feature."

Yes, it is a feature.  And yes, it does make sense.  Get only consumes a
line terminator if it sees one _before_ the next non-control character.

> Is this behaviour part of the specification for get()? 

You can read all about Text_IO in section A.10 of your handy-dandy
reference manual.

> Surely it would be designed to swallow that last /0 to prevent erroneous
> input? 

Surely ... not.  It only consumes line terminators that come before
non-control characters, not after.  

What you're suggesting doesn't make any sense.

If you want an operation to fetch a char and the line terminator that
_follows_ it, then use Get_Line.

> Has anyone come across this before??? 

Yup.  When I started learning Ada 12 years ago.

 
> I only ask because it appears to me to be a bit of an oversight on
> someone's part... ;) C ya W1bBle

Oh I agree with you, there is an oversight on someone's part...

My advice to you and everyone else is to always first use Get_Line to
transfer characters from standard input, and then internally vet and
parse the character string.

Don't bother with Get, Skip_Line, Integer_IO.Get, Float_IO.Get, etc.
Just use Get_Line.