4 ms·

Read the article comments for some of the pedantry on why C compiling has be painful forever. There is no keeping people happy.

dataflow 3y ago
I did read the article. Unless I missed something, I didn't see anything about why they couldn't add some mechanism to bypass these warnings for old files.
- kazinator 3y ago
  "They" (e.g. GCC maintainers) do. You have dialect options like -std=c90, and fine-grained control over diagnostics: you can disable or enable individual warnings, or have them treated as errors. GCC compiles C with a certain default dialect. It used to be gnu89 for the longest time, then gnu99 for a while. Now it is gnu11, if not higher. This default dialect is not ISO C; it's a GNU dialect. So just to have your code processed as ISO C, you have to use a non-default option. Some GNU extensions are still recognized (rather than diagnosed as syntax errors) so if you wish not to accidentally use those, you need -pedantic also. In Makefiles, you can tweak compiler options for individual files. E.g. with target-specific assignments in GNU Make. # don't warn about conversions in old_parser.c old_parser.o: CFLAGS += -Wno-conversion
  - anthk 3y ago
    Or use TCC or CParser for C89/C99 and much faster compiling times.
  - pjmlp 3y ago
    gnu17 on latest.
  - dataflow 3y ago
    The standard version is a TU-wide flag which doesn't help with headers. And it seems like the proposal here is to change the standard so that those legacy constructs are outright rejected. So my question was, if you're going to change the default in the standard, why not provide a per-header escape hatch for old code?
    - kazinator 3y ago
      I'm not sure which meaning/nuance of standard you are referring to, but the ISO C standard doesn't specify any flags mechanism, translation-unit-wide or otherwise. The GCC implementation (and likely Clang also) supports altering diagnostics over sections of a translation unit. https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

dataflow 3y ago

I did read the article. Unless I missed something, I didn't see anything about why they couldn't add some mechanism to bypass these warnings for old files.

kazinator 3y ago
"They" (e.g. GCC maintainers) do. You have dialect options like -std=c90, and fine-grained control over diagnostics: you can disable or enable individual warnings, or have them treated as errors. GCC compiles C with a certain default dialect. It used to be gnu89 for the longest time, then gnu99 for a while. Now it is gnu11, if not higher. This default dialect is not ISO C; it's a GNU dialect. So just to have your code processed as ISO C, you have to use a non-default option. Some GNU extensions are still recognized (rather than diagnosed as syntax errors) so if you wish not to accidentally use those, you need -pedantic also. In Makefiles, you can tweak compiler options for individual files. E.g. with target-specific assignments in GNU Make. # don't warn about conversions in old_parser.c old_parser.o: CFLAGS += -Wno-conversion
- anthk 3y ago
  Or use TCC or CParser for C89/C99 and much faster compiling times.
- pjmlp 3y ago
  gnu17 on latest.
- dataflow 3y ago
  The standard version is a TU-wide flag which doesn't help with headers. And it seems like the proposal here is to change the standard so that those legacy constructs are outright rejected. So my question was, if you're going to change the default in the standard, why not provide a per-header escape hatch for old code?
  - kazinator 3y ago
    I'm not sure which meaning/nuance of standard you are referring to, but the ISO C standard doesn't specify any flags mechanism, translation-unit-wide or otherwise. The GCC implementation (and likely Clang also) supports altering diagnostics over sections of a translation unit. https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html