From: "G.B.Rotman" <g DOT b DOT rotman AT stud DOT biol DOT ruu DOT nl>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: scanf/gets bug?
Date: Thu, 12 Nov 1998 16:55:58 +0100
Organization: Academic Computer Centre Utrecht, (ACCU)
Lines: 42
Message-ID: <364B050E.2140660@stud.biol.ruu.nl>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 981109101823 DOT 18112F-100000 AT is>
NNTP-Posting-Host: warande3077.warande.uu.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:

  On Sun, 8 Nov 1998, Daniël Hörchner wrote:

  > I came across a weird problem with DJGPP (GCC 2.8.1). In the following
  > program gets() should wait for input, but it doesn't. What's wrong?

  `scanf' leaves the newline in the input buffer, and `gets' swallows
  it.

  > The
  > strange thing is that if I insert a call to getch() between scanf() and
  > gets(), getch() waits for input, but gets() still does not.

  Not strange at all.  `getch' issues a low-level DOS call which
  bypasses the buffering of stdio functions.  The newline that causes
  `gets' to return immediately is in the buffer allocated by the stdin
  stream, which `getch' doesn't check.

  > With Turbo
  > C++ 3.0 it works fine (i.e., gets() waits for input).

  It works in Turbo C because this program uses a non-portable trick of
  calling `fflush' on stdin, which doesn't do anything in most
  implementations other than Borland's.

  A *portable* way of making sure the newline is not left in the buffer
  is to force `scanf' to consume it as well, like this:

        scanf ("%d\n", &x);

This doesn't seem to work, put a line like this
one in and scanf waits until it has been  given
two integers but it still leaves the newline in the
buffer. Isn't there a proper way to empty the
buffer?

Thanks in advance
and Greetings,
Gerben