scanf(), getchar() and Keyboard Buffer

[John Brake]

I've written a small C programme to demonstrate the use of scanf().  I want the console window to stay open after the summary display line (to prove the input worked), but it seems I need TWO getchar() to do it.

#include <stdio.h>
int main(void)
{
    int     age;
    float   number;
    printf("Please enter your age:\n");
    scanf("%d", &age);
    printf("Please enter the value of pi:\n");
    scanf("%f", &number);
    printf("You are %d years old and think pi = %f.\n", age, number);
   
    // For some reason, this programme needs two getchar() statements
    getchar();
    getchar();
    return (0);
}

I checked the value returned by the first getchar() -- it was 10... LineFeed.  Why wouldn't the LF be kept/discarded by scanf() along with CR?

This is annoying.  Any ideas of why it occurs?  Any simple solutions?  (Hmm.. possibility of using getch() from conio, but why use additional libraries?)

Thanks!
John

[Jim W.]

Try putting
fflush(stdin);
right after your last printf, and then comment out a
getchar();

Does that work?  Seems to work here....

-- Jim.

[John Brake]

Jim:

Yes, that works, thank you.

I'd still like to know why that LF is hanging around... just doesn't seem right or reasonable.

John

[qWake]

The scanf function reads a number and stops reading after all input for the number has been provided.  It does NOT read past that number because there could be additional data to read on that same input line (maybe, maybe not).

But this behaviour means that scanf does not remove the newline character that remains present in the input buffer, which was generated when the user pressed the ENTER key.  The result is that there is already a '\n' byte in the buffer when your first getchar() is executed, so that byte is read immediately without requiring user intervention.  So the program ends normally exactly as expected, unless you have added that second getchar().  Or unless you usef fflush(stdin) to clear the standard input after your last scanf.

qWake

[John Brake]

Okay... let me get this straight...

scanf() will leave the '\n' in the buffer for the next string or char read.

So, if I use:
int a, b;
scanf("%d",&a);
scanf("%d",&b);

If I enter "12\n", the "12" gets converted to 12, the '\n' stays in the buffer.  The next scanf() will read in "\n13\n", discard the first '\n' as irrelevant, convert the 13 and keep the ending '\n' in the buffer.

Why?  The only way to signal EOL on keyboard input is with LF from the <Enter> key.  scanf() is for keyboard entry.  Why would the people who wrote the function allow this (in my opinion) oddity?  Keeping that LF in the buffer just seems like trouble waiting to jump out at people.

I know that fgets() corrects this with stdin, but that's string input only.  I guess everything could be done in string with conversion of the values once the input is validated (okay, that's what >should< be done -- but walk first, then run).

It just seems odd to me.

Sorry, it seems that I'm whining.
John

[Jim W.]

Partly a guess here, but I think much of the confusion stems from Unix vs. DOS end-of-line conventions.  Toss it in with / vs \ in filespecs (or spaces/no_spaces, for that matter ).  Blame it on Bill Gates, and just keep on codin'....

-- Jim.