Switch to C11 instead of C89/C90

[kroeckx]

The main reason we were stuck on C89/C90 is that Microsoft Visual C didn't support anything more recent. Recent versions do support C11: https://docs.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170. Note that they don't support C99. I suggest we consider changing to C11.

[t-j-h]

No - the main reason we stick to earlier versions is so that OpenSSL can go across the widest range of platforms and that is not just on Windows. People work on a lot of platforms which are much older and on a pile of platforms where the compiler is much older too. Moving forward would cause more than a few challenges and for little meaningful benefit.

The OpenSSL community isn't in general sitting on the latest compilers on the latest platforms.

[h-vetinari]

C11 is the default since GCC 5.x, which can hardly be called the latest compiler (and covers a very wide range of platforms). The linux kernel is also moving to C11 in the upcoming merge window.

Not saying that this is directly applicable to OpenSSL, but the discussion itself makes sense IMO. What supported platforms would be affected and how? From https://www.openssl.org/policies/platformpolicy.html, it looks like probably NonStop (CC @rsbeckerca) and OpenVMS (documented as having some C99 support, though they seem to be moving to an LLVM backend, at least on x86).

This leads to a (potentially much) larger point why OpenSSL would willingly hold itself back to perform free(?) support for commercial entities like HP and VMS Software, but I acknowledge that this is not likely to change. Still, transparency on such constraints (and effective assumption of burden by OpenSSL) are IMO desirable, hence why I think this discussion is worth having.

[rsbeckerca]

Moving to c11 will exclude fixes to some legacy platforms still in use and maintained. I am happy to accept moving to c99 as a baseline, but not c11 for a few more years. We still have to support existing users. I do not see what the advantage is to moving to c11 - the functionality in the language is just not that broadly important in a pure C application. I understand a C++ motivation, but not in this situation. With respect, let me add that neither gcc nor Linux represent the entire universe.

[paulidale]

I'm honestly not see much that c11 gives that we'd use: the alignment specifications and maybe anonymous structs and unions. The third would be atomics but we've got them if compiler supported.

On the other hand, c99 has more things that might be useful: mixed declarations/code, variadic macros, // comments, designated initialisers, static array indices in parameter declarations and restrict. We already have long long and inline.

[t-j-h]

This issue has both technical and business implications (in terms of what platforms can be supported)
It would IMHO require an OMC decision to move forward on this (on the business side of things).

[mattcaswell]

On the other hand, c99 has more things that might be useful: mixed declarations/code, variadic macros, // comments, designated initialisers, static array indices in parameter declarations and restrict. We already have long long and inline.

I'm failing to see a killer must-have feature from that list:

• mixed declarations/code: I don't care (probably this is a matter of taste, but I actually prefer code that doesn't do this)
• variadic macros: Could be useful in some very specific cases
• // comments: I don't care
• designated initialisers: Nice to have
• static array indices: Nice to have
• restrict: Not sure....but probably nothing more than "nice to have"

[t8m]

I agree with Matt - I do not really see that great benefit from moving to C99 (or C11).

[kroeckx]

For a list of changes in C99 and C11 see: https://en.wikipedia.org/wiki/C99 and https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

We make use of several features of both C99 and C11. This includes at least: inline functions, long long, snprintf, inttypes, multi-thread, atomics. By not requiring C99 or C11 support, we need to add code to support platforms that don't support it. This has a cost.

There are also other features not mentioned here that might be useful: booleans, type-generic expressions, unicode support, and static assertions.

[rsbeckerca]

For a list of changes in C99 and C11 see: https://en.wikipedia.org/wiki/C99 and https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

We make use of several features of both C99 and C11. This includes at least: inline functions, long long, snprintf, inttypes, multi-thread, atomics. By not requiring C99 or C11 support, we need to add code to support platforms that don't support it. This has a cost.

There are also other features not mentioned here that might be useful: booleans, type-generic expressions, unicode support, and static assertions.

Personally, I have had a lot of success with c99 as a baseline compatibility on all platforms I work with (NonStop, z/OS, cygwin, Ubuntu, Debian), so if I had a vote and needed to take a position on minimum compatibility, I could live with c99.

[h-vetinari]

I agree that C11 doesn't have much in the way of "killer features". One meta-point in favour of bumping standard versions is to make it a "habit" (well, as reasonably as possible given the 12 year cadence), however that might look like, even if it's +15 years after release - otherwise OpenSSL assumes the cost of forgoing any and all possible improvements afforded by newer standard versions.

In that way, even just a bump to C99 would be desirable, just to get people and consumers used to the fact that this is not engraved in stone tablets, and running a platform means keeping the relevant compiler up-to-date with ISO C (with an exceedingly generous time buffer).

Regarding C99, it's worth noting that several features became optional in C11, and since MSVC does not support the C11-optionals, it would probably then have to be something à la "C99 without the features that became optional in C11".

[mattcaswell]

OTC: The approach to do this would be to create a PR against the coding style. @kroeckx if you want to pursue this please create a PR