Context: C2x (as well as previous) doesn't seem to define the limit on the number of diagnostic messages produced.
Does it mean that there is no limit?
If so, then why some C compilers (clang, msvc) do have limits (20 errors and 100 errors respectively)?
Demo:
# clang
$ for i in {1..100}; do echo int $i\x\; ; done > x.c && clang x.c -std=c11 2>&1 | grep 'error:' | wc -l
20
# msvc
$ for i in {1..100}; do echo int $i\x\; ; done > x.c && cl x.c /std:c11 /Za 2>&1 | grep -P 'x\.c\(\d \): error' | wc -l
101
# gcc
$ for i in {1..100}; do echo int $i\x\; ; done > x.c && gcc x.c -std=c11 2>&1 | grep 'error:' | wc -l
200
Reason of the question: some C compiler diagnostics tests have many test cases in the same source file. Hence, they expect that the C compiler can produce as many diagnostic messages as (at least) the number of test cases. Surprisingly, by default clang have 20 errors (can be changed via -ferror-limit
) and msvc have 100 errors (cannot be changed, because it is hardcoded).
Extra: Should clang -std=c11
implicitly use -ferror-limit=0
?
CodePudding user response:
The C standard only requires one diagnostic regardless of how many errors a translation unit has (if there is at least one). C 2018 5.1.1.3 1 says:
A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined…
This does not say an implementation shall produce one diagnostic message per violation, just that it shall produce at least one diagnostic message if there is a violation.
An implementation is free to terminate after identifying one violation.
This text is identical in draft N2731 for some future version of the standard.
CodePudding user response:
The main reason for limiting diagnostics is that very often one tiny error cascades into many many diagnostics. At some point it makes sense to simply give up rather than continue spewing meaningless drivel.
The fact that it's deliberately undefined means that it is up to the implementation to choose when that point is reached, or whether there is any limit at all. And note also that very often some earlier error means that messages about later errors do not actually help track down those errors.