macOS Odd loop/printf behavior in C

So, I was testing my understanding of the syntax for do-while loops and the toupper() function and ran into an odd error.
What is happening is, after the initial run it is printing "Type something in please:" and the newline in the printf that displays the result is printing twice. I suspect this has something to do with the keyboard buffer (still working on learning about that, so explain it in basic terms please )
Can anyone help me with a workaround/fix for this?

toddburch said:

Yes. What is happening is that there are 2 characters in the input buffer when you press ENTER: the lowercase character and the NEWLINE character.

After you scanf() the lowercase char, you can do a getchar() (or a loop of getchar()s) until the NEWLINE is removed from the input buffer.

See this link: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044873249&id=1043284392

Todd

Click to expand...

Thank you, that was very helpful.
So can anyone help me see if I understand this:
When you first something in (for example, t) the t is sent to the keyboard buffer and NOT directly to the program.
It is only sent to the program when the user presses Enter/Return. Pressing Enter adds a newline character to the buffer. However, enter is pressed, only ONE of the characters is actually sent to the program. The t is sent to the program. Thus, the scanf() function ONLY gets the first character- the t. The newline key, still in the buffer, is gotten by the scanf() function when the loop repeats, causing the input to appear blank. This can be worked around by adding a getch() after the first input to "snag" the newline.

toddburch said:

Yes, that is correct.

If you were to enter

abcd\n

The loop would repeat 5 times.

This is all predicated on the fact that you told scanf() to use a single character (%c) in the format specifier.

Todd

Click to expand...

Thank you again.
Also, does that mean that this could be worked around by making it a string instead of a single character?

Sander said:

You should consider thinking about interactive user input in terms of "lines", not of "characters" - even if those "lines" actually only contain (or should contain) a single character plus newline.

Click to expand...

Oh, that cleared a few things up... thank you.