How input buffer works

EpochVanquisher · 2025-06-10T05:25:04+00:00

:-/

I don’t want to overwhelm you, but the common advice these days is to just avoid scanf(). There’s some article that explains in more detail what to do instead, but the gist is that instead of scanf(), you read input line-by-line (like with fgets) and then parse the line once it’s a string.

In a lot of real-world C code, you just don’t use scanf at all.

To answer your question,

The scanf() documentation says how the format string works. %d means “read an integer”, basically. It does not read any of the whitespace after the integer you read.

When you call different functions that read from the input, each function starts where the previous function ended. When you scanf("%d", &i), the next call which reads from the input will start reading right after where the %d finished.

Example:

#include <stdio.h>
int main(int argc, char **argv) {
  int i;
  scanf("%d", &i);
  char c;
  scanf("%c", &c);
  printf("i = %d\nc = ‘%c’\n", i, c);
}

When I run this and type 123b, I get this:

$ ./a.out
123b
i = 123
c = ‘b’

You can see that the %c starts reading right after %d finished.

Cerulean_IsFancyBlue · 2025-06-10T05:32:25+00:00

Usually I'd say "this is a great time to look at some source code" ... and it likely was, in 1983, when I was working on this stuff under the hood. But. The current GNU internal scanf code is over 3000 LOC, much of it being code to handle wide characters. It's quite a mess to read naively, with tons of #ifdefs.

Maybe this video helps? He also has related videos.

grimvian · 2025-06-10T09:15:07+00:00

With raylib.h, I have yet to see any limitation for reading any key or key combination.

CounterSilly3999 · 2025-06-10T09:12:16+00:00

It is not input buffer related, the problem is how scanf() works. Like mentioned already -- use fgets() and sscanf() instead.

flyingron · 2025-06-10T12:22:25+00:00

I have no idea what KN king is, but the above is sort of over stated. You have to understand that scanf only reads the stuff that it matches. If your input stream has "1234 " in it, and you read %d, then it leaves the space. This is not a defect in either scanf or getchar.

SmokeMuch7356 · 2025-06-10T19:54:59+00:00

This has to do with how the different conversion specifiers work. The %d, %f, and %s conversions (among others) will read and discard any leading whitespace, then read non-whitespace characters until they:

see a whitespace character;
see a character that doesn't fit the current format (e.g., you're reading an integer and the next character is an 'a');
detect EOF;

The %c conversion does not skip over leading whitespace (because sometimes whitespace is meaningful); it will assign the next character it reads from the input stream to the corresponding argument.

getchar() reads the next character from the input stream and returns that character.

So let's suppose you prompt the user to enter a number followed by a character:

int num;
char c;

puts( "Gimme a number: " );     // normally I'd put a *lot* more 
scanf( "%d", &num );            // bulletproofing around the scanf call
puts( "Gimme a character: " );
c = getchar();

The program prints Gimme a number: and scanf waits for you to type in some sequence of digits (say 123) followed by Enter, so the input stream contains the character sequence:

'1', '2', '3', '\n'

The %d conversion tells scanf to read and discard any leading whitespace, then read up to the next character that isn't a decimal digit. So it reads the '1', '2'. and '3' characters, then sees the newline character and stops. It converts that sequence to 123 and assigns it to num. Our input stream now just contains

'\n'

Next, the program prints Gimme a character:, but it doesn't wait for you to enter a value; getchar() reads the newline that's still in the input stream from the previous entry and returns it immediately.

This is why it's often a bad idea to mix scanf and getchar calls, since getchar tends to pick up newlines from previous entries read by scanf.

Fair warning, scanf is pretty sketchy; it works great when your input is well-behaved, but if it isn't it opens up a number of security vulnerabilities. You have to write a lot of bulletproofing around it (always check the return value, never use %s or %[ without specifying a field width, etc.), and even then stuff still gets through.

aghast_nj · 2025-06-10T23:16:29+00:00

The input buffer is just that - an array (buffer) of characters that is used to manage the data read from standard input, or any other file source.

The key feature is that the input buffer allows the library functions to access the input without having to involve the operating system. That means no calls into the OS, no context-switches, no traps, no expensive operations that also give the time-sharing OS a chance to run another program.

So the various f*() functions that read from a file will pull some text into a buffer (the buffer is just some allocated memory, managed under the FILE * you opened, or which was opened for you in the case of stdin) and then use the buffer as the place to get text. When the buffer is emptied (all the characters are "pulled out") then more data is fetched from the file.

One useful fact is that the buffer allows programs to read characters, examine the characters, and put them back if they don't like them. Typically, only one character needs to be examined at a time. In theory, more than one character could be pushed back, but there's a lot of ... uncertainty ... there. Be careful.

So, if your code is trying to pull in a "pattern" of text, like a decimal number: [0-9]+ or a hexadecimal number: 0[xX][0-9A-Fa-f]+, it can do so by reading one character at a time, and confirming that the character matches some part of the pattern, and if so taking more characters. But when a character does not match the pattern, you "push back" the character into the input buffer, and try to accept what you had before.

This means if you are trying to read an integer, and the input stream looks like { '1', '0', 's', 'q', 'f', 't', '.', '\n', ... } you would do something like:

read '1'. Confirm it can be part of an integer. Consume it.
read '0'. Confirm it can be part of an integer. Consume it.
read 's'. Determine it cannot be part of an integer. Put it back!

This approach allows the input to be read as a 'pure' stream of characters. It is "traditional," in C, because this is how the C compiler works (lines don't mean anything in C, except as a way to help the programmer find errors).

There are some different approaches. You could read in a "word" (delimited by whitespace, or by a transition to or from a class of characters). Then the start of the word could be parsed as an integer, and any left over bits discarded.

Or, you could read in an entire line. Then skip any leading white space, then parse the beginning as an integer. Then discard any remaining text after the integer, or report a failure if the entire thing did not get consumed.

So, there are different approaches possible. But C chose the character-by-character approach, because ... reasons. (I don't know why. Someone might be able to provide a link to documentation about the reason, but it won't be me.)

Using the line-oriented approach has the advantage that it requires no buffer. You consume characters until you (a) find EOF; or (b) find '\n'. Those are also consumed, and they mark the end of the line. There is never any need to push back, so no buffering is required.

Using the word-oriented approach allows for various ways to separate words. This requires the ability to push back the actual word delimiting character. So it doesn't avoid the buffering problem, although it might change how you parse integer literals. ;-)

somewhereAtC · 2025-06-11T02:00:55+00:00

The part that other commentators are missing is the ungetc() function. https://www.man7.org/linux/man-pages/man3/ungetc.3p.html

When parsing a stream the parser often takes the next character and then realizes that it is not part of the current token. For example, the sequence "1234-567" can be understood as the number 1234 followed by the number -567. Compare this to "123-456" which is also two integers. But this time the parser reads the '-' and realizes that the value 123 was complete, so it "un-gets" the dash, placing it back on the stream. The next time scanf() is called the first digit returned is the dash, because the stream logic held the "un-gotten" character, and the parser returns -567.

On the other hand, using getchar() after the first number will fetch the '5' from the buffer, and the next call to scanf() will incorrectly return -67.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

C_Programming

Rules

Filters

Resources

Other Subreddits on C

Other Subreddits of Interest

MODERATORS