Thread: stdin buffer size

I doubt that you have a situation where input is going missing. It is perfectly valid to read from the input, wait 6 minutes (or 2 days, or 9 months while a baby is formed until it's born, if you like).

So unless you are using some OS that is really obscure (small time RTOS or some such).

--
Mats

The stdio buffer size definitely has nothing to do with this problem. The buffer size impacts performance, not behavior.

I'm not sure, but:

Code:

while (1) {
      if (!fgets(line,1024,stdin)) continue;
      func(line)
}

will create an infinite loop that consumes all available CPU power (of one CPU(-core)) if you ever hit an EOF. Are you sure the "continue" shouldn't be a break?

--
Mats

Just a guess: the OP intends to try again if fgets() doesn't get anything -- which is conceptually wrong, since there would be a real reason for the NULL return, and fgets will not return NULL because it is "waiting" for input (it will wait). I don't use fgets, but I can't see how it would ever return NULL from stdin anyway, presuming stdin is the keyboard and not from redirection.

The real problem must lie in func().

If by fast vs. slow input you mean something to do with the keyboard, you are way off base -- it is not possible to type fast enough to be anything but "incredibly slow" to the computer, so that cannot be a factor.

fgets returns NULL from stdin if:
1. stdin is redirected to a file or device and the file/device has been read to the end.
2. if stdin is not redirected, when the user presses the CTRL-Z (Windows, DOS, CP/M and a few others) or CTRL-D (Unix and Linux and such) to indicate "I'm done entering stuff here".
3. If something ELSE goes wrong (I'm not sure exactly what would cause this, but at least in theory things CAN go wrong inside the stdio functions!).

--
Mats