Not including a linter in the earlier C compilers are one of the hughe mistakes of that area. Compilers absolutely should have linters, they are very valuable tools. Think about all the
common security mistakes in your average C application that could have been avoided over the years with a linter.
I'm pretty sure Dennis Ritchie at some point himself said that not including a linter was a mistake, but I cannot find a quote of this with a quick search.
He at least said that it was a requirement for the buggy code he saw being written.
"To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."
Back in the day most people actually ignored the few warnings compilers would give them, i do not think that having a linter would be used much (and AFAIK there were some).
"Back in the day?" Check out your system's log file for a scary collection of horror shows. Or compile most packages these days.
In defense: configuring a package that is compiled by lots of people on lots of machines with lots of versions of various compilers requires a lot of attention to warning flags and such. If you aren't starting out a package from a blank buffer it's very hard to get this right.
But I am frequently shocked by the number of compiler warnings I get from code downloaded from public repos and compiled in precisely the environments it's been documented to have been tested on.
I'm pretty sure Dennis Ritchie at some point himself said that not including a linter was a mistake, but I cannot find a quote of this with a quick search.