The fundamental problem here is that C compilers just don't have enough information about your code. An "unsafe pattern" that might warrant a warning in one place may be crucial in another.

Rust's innovation here is that it can separate these cases based on lifetime annotations on functions and types, where the program text itself disambiguates its intentions.

So to get much closer than current -Wall -Wextra, you need to either impose some default assumptions (the C++ core guidelines do this) or start adding annotations somehow.

That is pretty challenging, actually. The C language spec allows about anything with the semi-colons in the right place. Without more strictures in the language spec there is nothing to raise errors about.

Now you can ask for lots of warnings, -wall, but I suspect many people turn that off after the first ASCII tsunami.

another thing worth noting is that many projects need to support multiple platforms, which means multiple different compilers. good luck getting a large project to build on clang or gcc and msvc without warnings. i've run into cases at work where it seems like i'm going to get a warning from at least one of the compilers no matter what i do (barring complicated #ifdef/#pragma salad).

-Wall is a pretty low bar nowadays. There's some resistance to adding more to it, so you also have to enable -Wextra. I do at least those for all new C code.

And even those two doesn't get you everything. Clang's got -Weverything, but the developers suggest it's an internal feature and shouldn't be used. From there you have to manually identify and add -Wfoo options.

I agree. I'd like to see C compilers that were even pickier about warnings than current compilers with -Wall. Compilers should be able to pick out more unsafe patterns and practices than they do, and warn about them, even as they accept the code as valid C.

When I write my own code I turn on as many compiler warnings as I can, and make sure it compiles clean. If there were more warnings I'd turn them on.

Problem is usually third party libraries. Plenty of open source projects don't give a single shit about compiler warnings and unsafe practices. So if I include a header from libSomething package, here come 10k warnings. I remember one project (don't remember which one) specifically said in its documentation something like "don't submit patches to fix compiler warnings, it's impossible to keep up with every complaining compiler out there." With programmers like that out there, what hope do we have?

It's usually possible to selectively disable warnings for 3rd party code. A last-ditch approach is to use the following around an include:

    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wfoo"
    #include <my_3rd_party_header.h>
    #pragma GCC diagnostic pop

E.g., https://stackoverflow.com/questions/3378560/how-to-disable-g...

(Despite the "GCC" moniker, Clang supports the same approach.)

> Some of this could be improved with better C compilers, right?

Not significantly, not as long as they are C compilers and thus accept all valid C code.

Depends on what you mean by "accept," doesn't it?

Yes, without -Werror, C compilers won't act on diagnostic warnings. But C compilers can and do warn about "valid C code" that happens to set off alarm bells.

And with -Werror, they reject some valid C code.