Clarify and document C and C++ standard support

[LocalSpook]

We seem to have a quite complex system of C and C++ standards we support, and this system has no documentation. Please help me understand the situation and correct me if I'm wrong anywhere.

C standards

• It seems like the core lz4 library and CLI (everything under lib/ and programs/) is targeting C90 when compiling a release build. No //-style comments, declarations only at the top of blocks, etc. But the support seems incomplete. For example, the only reason make c_standards_c90 succeeds is because it compiles with -Wno-long-long -Wno-variadic-macros. Why are these incompatibilities allowed, but others aren't? When compiling with LX4_DEBUG defined, there are even more incompatibilities (%z specifier in printf(), for example).

• The contrib/ directory seems to have no restrictions; any language, any standard.

• examples/Makefile forces GNU99 (CFLAGS += -std=gnu99) but examples/ compiles perfectly fine as C99 and later standards.

• The ossfuzz/, examples/, and tests/ directories seem to target C99 (they certainly don't compile as C90), and yet in those directories there is code that looks like:

#if (defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)

Should this be removed?

• We don't have a make c_standards_c17 test. Is that because C17 is too similar to C11 to be worth the trouble?
• We don't have a make c_standards_c23 test. Is that because C23 is not supported well enough yet?

C++ standards

• We have make ctocpptest, which ensures lz4/ and tests/ can compile as C++ (no standard specified).
• We have make cxx17build, which ensures lz4/, tests/, and programs/ can compile specifically as C++17. Should it be added to CI? Should there be corresponding cxx11build, cxx20build, and so on?
• examples/Makefile enables the -Wc++-compat flag, which isn't used anywhere else. Should it be added to the rest of the project, or at least lib/, tests/, and programs/?

[t-mat]

Why are these incompatibilities allowed, but others aren't?

As for -Wno-long-long, because we need this feature.
But we also want to be friendly with C89/C90 as much as possible to support limited environment such as embedded, console, MSVC (before 2019), etc.
Fortunately, many of pre-C99 compilers had compiler/platform specific "unsigned long long" as 64-bit unsigned integer.
Therefore, for practical reason, we have these exception/incompatibilities.

Since we don't have any issue with this "incompatibility", it seems okay for our users.
(I know closed environment users modified the type of U64 locally for their compiler though)

[t-mat]

Should this be removed?

Since many of them can be compiled with -std=gnu90, it'd be nice to leave them as is.

We don't have a make c_standards_c17 test. Is that because C17 is too similar to C11 to be worth the trouble?

I personally think we can ignore C17 at all. Because we don't (and won't) use deprecated feature.

We don't have a make c_standards_c23 test. Is that because C23 is not supported well enough yet?

Actually, we already have C23 notation ([[deprecated]]) as a part of C++ support.
So, when we'll decide to use C23 standard feature, it should be tested.

We have make cxx17build, which ensures lz4/, tests/, and programs/ can compile specifically as C++17. Should it be added to CI? Should there be corresponding cxx11build, cxx20build, and so on?

It's great to have them on CI environment. We'll need to make compilers × C++ versions support matrix though.

examples/Makefile enables the -Wc++-compat flag, which isn't used anywhere else. Should it be added to the rest of the project, or at least lib/, tests/, and programs/?

I think they don't need it. Because they have cxxtest which ensures C++ compatibility by actual C++ compiler.