This is fgets()
's official prototype:
char *fgets(char *str, int n, FILE *stream);
Why specify the size (n
) ? Is it to prevent buffer overflow of some sort? Or is it just a design flaw?
I would think that it's caused by gets()
tendency to cause buffer overflow and segfault your program, but that's only my guess.
In any case, this may be related to the fact that fgets()
is a file function, but I would also have no idea.
This is in the context of a recent video on buffer overflow, and in a security context, is this a risk? Is the size a limitation, and in this context, prone to segfaulting?
Why does fgets() require a maximum size of user input?
To limit the amount of data that is saved - preventing buffer overflow cases.
Why specify the size?
To prevent fgets()
from saving too many characters.
It also stops reading characters.
fgets()
could have read excess characters in a line and not save them, yet the design is to read up to size - 1
characters and save them and then append a null character. If the buffer fills without a '\n'
, the rest of the line remains to be read.
Is it to prevent buffer overflow of some sort?
Yes, this prevents a buffer overflow. It also stops the reading of characters from the file.
Or is it just a design flaw?
It is by design as a limiting alternate to code like gets()
(no longer parts of the C library) and scanf("%s", ...
which remains risky.
Other (and later) functions that specify the buffer size are of type size_t
. fgets()
with its int size
is a minor design flaw.
and in a security context, is this a risk?
Passing in a limiting size reduces risk.
Is the size a limitation, and in this context, prone to segfaulting?
The size reduces segment faults.
Reading a line in C is only partially handled by fgets()
.
Issues remain (some are pedantic):
How to detect and handle when not all the line was read?
Quieting unsigned_to_signed warnings that come up when a size_t
variable is passed as the size
.
Detecting the number of characters read when fgets()
unusually reads a null character as strlen()
, to find the number read, will stop on the read null character and not the appended one.
Many applications do not want to save the '\n'
. So when the destination is size n
, code needs additional helper code to read and save up to n-1
characters and then lop off the possible '\n
or maybe still read if the buffer was full.
There are 4 reasons why fgets()
stops reading: '\n'
read, full buffer, end-of-file detected, rare input stream error occurs. Additional code must be careful to discriminate.
A size of 0 or negative is a pathological problem.
C deserves a better readline function.