Quoth Alejandro Colomar:
I think I found a bug in POSIX.1-2017 (and probably, previous ones too, but didn't check). <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html>: {LINE_MAX} Unless otherwise noted, the maximum length, in bytes, of a utility’s input line (either standard input or another file), when the utility is described as processing text files. The length includes room for the trailing <newline>. Minimum Acceptable Value: {_POSIX2_LINE_MAX} It doesn't say anything about the trailing null byte for the buffer that holds it, but I assume it doesn't include it, from the context. However: <https://pubs.opengroup.org/onlinepubs/009695399/functions/fgets.html>: The following sections are informative. EXAMPLES Reading Input The following example uses fgets() to read each line of input. {LINE_MAX}, which defines the maximum size of the input line, is defined in the <limits.h> header. #include <stdio.h> ... char line[LINE_MAX]; ... while (fgets(line, LINE_MAX, fp) != NULL) { ... } ... This example seems to contradict my understanding of what limits.h says. So, either limits.h should be explicit that the trailing null byte is also included in LINE_MAX, or the example is bogus and should be fixed. I guess it's the latter, although I wish it was the former, so we can avoid a +1 in the code. In any case, could you please forward this to the Austin group?
Good find. You aren’t the first one to find it: https://austingroupbugs.net/view.php?id=182 discusses that example a little. The desired action written there appears verbatim (bar formatting) in the 4.1 draft of POSIX.1-202x.
