I never understood why scanf(3) is taught to new programmers.

fgets(3) is way simpler, and easier to use. And scanf(3) is in general avoided outside of teaching, so it would be better to avoid it entirely. fgets(3) also helps programmers think of text files, which is usually a good format.

Here's what the manual page says about it:

     The scanf() family of functions scans  formatted  input  like  ss‐
     canf(3),  but read from a FILE.  It is very difficult to use these
     functions correctly, and it is preferable  to  read  entire  lines
     with fgets(3) or getline(3) and parse them later with sscanf(3) or
     more specialized functions such as strtol(3).

alx‭ The whole of stdio.h is just unimportant to learn since the whole lib is far too poor to be used in professional programs, always was. fgets for example has a bad API that never got fixed, you can never know how much it read. People need to stop recommending fgets - the proper recommendation is to stay clear of the entire stdio.h.

Why would you want to know how much it read? If you really want to know, it should be as simple as strlen(buf), which yeah, might be a bit inefficient, but compared to reading a file, is that observable? Or does it have any obscure/dangerous/tricky behavior?

What do/would you use instead?

alx‭x When you are reading from all manner of streams and files - not just stdin - then the nature of the input can be garbage or incomplete, or you hit end of buffer/file. When that happens, you would like to know how much it was able to read before hitting the end, since that isn't necessarily an "error" scenario but normal use, working with variable buffers/files. When designing an API that reads from a stream/buffer/file it is standard practice to use two different parameters: one telling the function how large the pre-allocated output buffer is and another that the function can use to fill in how many bytes it actually wrote. As reference, a somewhat well-designed API is the semi-modern (1990s) Windows API where you'd have parameters nNumberOfBytesToRead and lpNumberOfBytesRead. A whole lot better than stdio.h or read/write etc: old crap functions with broken API from the 1970-1980s.

Lundin‭

If I understand correctly, you mean when reading files that are not text files. Of course, fgets(3) is not good for reading non-text files. But that's not because fgets(3) is a bad API, but because it's not suitable for non-text files. There are APIs for non-text files.

For text files, fgets(3) is a good API (IMO).

For non-text: Doesn't fread(3) do that? It asks for the buffer size (it actually asks for the element size --often one--, and the number of elements in the buffer). It then returns the number of elements read.

Actually, it has some issues with the return value, since it returns a number of elements, but that might not exactly match the number of bytes read, so you probably want to call it with an element size of 1 and then pass n*size as the number of elements. Any other issues with it? I'm honestly not too familiar with fread(3), since most of the files I use are proper text files, and imperfect files are rejected as errors.

alx‭ No, when reading streams. They are usually text, but not necessarily sanitized. It could be a file, command prompt input or incoming data from a serial port. Quite likely unknown amounts. What am I to do when I want to verify a chunk of text of an unknown amount? Well, first of all I probably got to iterate over it yet again to determine the size, because fgets was too lazy to tell me as much, even though it knows the size read internally. Really bad API, period.

POSIX defines text files (that includes streams) as being composed of 0 or more lines. And lines are defined to not contain null bytes and be no longer than LINE_MAX characters (including the '\n', but not the '\0' of the string in which it is stored).

If a stream contains null bytes, or doesn't respect the length, then it's not a valid text stream. In any of those two cases, the validation should be performed by the program. If the buffer passed to fgets(3) was of LINE_MAX+1 elements, then validating the lines is relatively simple:

I wrote a function for doing that:

char *
stpsep(char *s, const char *delim)
{
	strsep(&s, delim);
	return s;
}

Which I use as:

while (fgets(buf, countof(buf), stream) != NULL) {
	if (stpsep(buf, "\n") == NULL)
		errx(EXIT_FAILURE, "Non-text file");
	...
}

After that stpsep() check, the input line is validated. Should fgets(3) validate the line? Maybe. Would it result in simpler code? Not much.

Lundin‭

And I forgot to mention the obvious: POSIX also requires that all lines are terminated by '\n'. If a line doesn't contain that '\n', it's invalid.

And also forgot to mention: stpsep() does two things: it validates the line, and it removes the '\n'. Both at the same time.

Lundin‭

I've been thinking about how an ideal fgets(3)-like API would look like, and I've developed an API that I think I like slightly more than fgets(3).

// fgettextline - FILE get text line
char *
fgettextline(char *buf, size_t n, FILE *stream)
{
	if (n > INT_MAX) {
		errno = EOVERFLOW;
		return NULL;
	}
	if (fgets(buf, n, stream) == NULL)
		return NULL;  // fgets(3) sets errno on error (in POSIX).
	if (stpsep(buf, "\n") == NULL) {
		errno = EILSEQ;
		return NULL;
	}
	return buf;
}

This allows moving the error handling out of the loop.

errno = 0;
while (fgettextline(buf, countof(buf), stream) != NULL) {
    // validated string here, with the '\n' stripped.
    ...
}
if (errno != 0)
    err(EXIT_FAILURE, "fgettextline");