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: W1bBle Subject: Re: Weird get_line() Date: 1999/03/28 Message-ID: <7dmci4$qgd$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 460116563 References: <7dlbot$co$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x1.dejanews.com:80 (Squid/1.1.22) for client 195.11.50.204 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sun Mar 28 23:04:41 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: IBrowse/1.22 (AmigaOS 3.1) Date: 1999-03-28T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: > W1bBle writes: > > > I have an extremely strange problem with get_line() > > > > In the main part of the program, it functions as normal. However, when it is > > used inside a loop (like you would need to implement a basic text menu on > > your terminal) the program appears to "skip" over the get_line() statement, > > removing the possibility of user input, which kind of defeats the purpose of > > having a menu. get() suffers no such problems. Any ideas? I'm using the > > gnat system. > > Make sure your line buffer is larger than (and not just equal) the > user's input. > > Remember that the buffer holds both the actual data entered by the user, > and an indication of whether the entire line has been consumed. > > See my response to the post "Sequential???" on 23 Jan 99 for an > explanation of how Get_Line works. > > OK, thanks but I already knew that (like in C where you need an array one bigger than the string you have to hold, to handle the /0 chracter). Anyway... 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. This made the get_line() immediately following it think that you had pressed return. It just processed whatever was left in stdin. 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. 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." Is this behaviour part of the specification for get()? Surely it would be designed to swallow that last /0 to prevent erroneous input? Has anyone come across this before??? I only ask because it appears to me to be a bit of an oversight on someone's part... ;) C ya W1bBle -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own