though VS is the only C compiler I know of that (until recently?) doesn't support most of C99
It's a bit more complex than that. Let's dig into the details.
GNU, as usual, does whatever the hell GNU wants. Unless one tells it otherwise, gcc's supported features changes pretty much every release and tends to be wildly unpredictable. This can result in some interesting side effects for advanced programmers. e.g., tricks to build custom memory allocators were recently 'optimized' away.
Most non-GNU-based compilers that I've worked with default (usually) to C89 with extensions (e.g., C++ style comments). This is primarily due to C99 being incompatible with previous C standards. (new keywords, int declarations, ...) In order to tell the compiler that no, really, we want to use C99 and not to barf on the incompatbilities, then (minimally) a flag has to get passed or (maximally) a different compiler executable (hi DPW) needs to get used. If we want to declare this code base as being C99 then we need to tell cmake to make sure we're using a C99 compiler. Until we do that, this code is defaulting to non-C99.
In addition, we would also need to audit the code to make sure that we really are writing C99. That shouldn't be too difficult, but it is something that needs to happen. Minimally, compiling with something that isn't gcc in C99 mode would likely highlight the problem areas since gcc tends to be... forgiving.... without --pedantic.
Bonus: telling cmake that we're doing C99 is sort of a mine field, depending upon which version of cmake is in use.
If there are restrictions on the subset of C this should use, the compiler needs to enforce them.
Totally agree. But the end result is we can't just declare we're writing C99 and then expect the compiler to magically know that.
As I said above, my #1 issue with this patch is the lack of a unit test. If someone wrote a method that determined if experimental/insecure features were enabled in the heart of the Java authentication code based upon a site.xml setting, I'm fairly confident that the contributor would be adding and anyone reviewing would flag the need for even a basic unit test, if not true, false, & broken input tests. In one sense, I understand why the community at large treats the non-Java code as coming from a lower caste, but c-e is one of the most important parts of the source base. It really does require extra scrutiny and the lack of even a basic unit test when it's clearly possible should be a huge red flag.