Switch to C99 without the features that became optional in C11

[levitte]

How do we handle old compilers, on platforms where there isn't any choice? Will it be sufficient to add compatibility functions and macros, or are we thinking of supporting syntactic things that just aren't possible on those (for example, field specifiers when setting the value of a union)?

[kroeckx]

We already have compatibility for such platforms. We have plenty of code that's there just because we want to use C99 and C11 features that are not available on all platforms. But as far as I know, we don't have a platform in our platform lists that doesn't support C99, which includes things like Sun C and djgpp. This change in policy will allow us to remove such compatibility.

[t-j-h]

I don't believe that there are any C99 features that are sufficiently important to move forward to that language version. OpenSSL is used on a large range of platforms that go well beyond the official list. We would also have to continue with C89 level support for all current releases.

[hlandau]

What are the features in C99 we actually want?

Taking a list of features from Wikipedia:

inline functions

We already have our own macro for this.

intermingled declarations and code

Would be nice, but major stylistic change, so probably undesirable.

several new data types, including long long int, optional extended integer types, an explicit boolean data type, and a complex type to represent complex numbers:

Bool would be nice and easily polyfilled on platforms which don't have it. Complex probably has poor support and I can't see us needing it. long long we already use.

flexible array members

This doesn't really buy us anything and probably has poor support.

support for one-line comments beginning with //, as in BCPL, C++ and Java

Would be nice, but major stylistic change, so probably undesirable.

new library functions, such as snprintf

We use our own implementation of printf in BIO, so this doesn't really matter to us.

designated initializers (for example, initializing a structure by field names: struct point p = { .x = 1, .y = 2 };)[5] compound literals (for instance, it is possible to construct structures in function calls: function((struct x) {1, 2}))[6]

Would be nice but not a game-changer. I think we would need to survey support on our target platforms (VMS, NonStop, ...)

support for variadic macros (macros with a variable number of arguments)

Probably the most useful thing in C99 for us. This only affects the preprocessor.

restrict

Desirable. We can use a macro for this so we can compile it out on platforms that don't support it. We can adopt this whether or not we adopt C99 in general.

I think aside from creating an ossl_restrict macro the only things useful to us are _Bool and variadic macros. We could also create an ossl_static_assert macro for platforms which support C11 static assert. Of these the only things which can't be polyfilled/no-opped on platforms which don't support them are variadic macros. So the question is whether all platforms can support them.

[beldmit]

Personally I like boolean, declaring cycle variables inside the cycle itself and //-style comments. long long looks like a bad idea to me, I prefer explicitly sized types.

[t8m]

long long looks like a bad idea to me, I prefer explicitly sized types.

We already need and use it on 32 bit platforms for 64 bit numbers. (And yeah mostly as a typedef to int64_t)

[levitte]

designated initializers (for example, initializing a structure by field names: struct point p = { .x = 1, .y = 2 };)[5] compound literals (for instance, it is possible to construct structures in function calls: function((struct x) {1, 2}))[6]

Would be nice but not a game-changer. I think we would need to survey support on our target platforms (VMS, NonStop, ...)

support for variadic macros (macros with a variable number of arguments)

Probably the most useful thing in C99 for us. This only affects the preprocessor.

These two would be useful, but seriously precludes older compilers / pre-processors, as these are syntax features that can't be replicated with smart functions or macros... That being said, current VMS (v8.4) with a current C compiler (v7.4) seems to fully support C99

[kroeckx]

My understanding of the current situation is that we currently use those unconditionally:

• long long int
• flexible array members (not sure if we still do)
• snprintf

We use those conditionally:

• inttypes (like uint64_t)
• inline functions

Things that look useful that we currently don't use:

• intermingled declarations and code
• booleans
• designated initializers
• variadic macros
• restrict
• Unicode (wchar_t)

Things that some people might want to use:

• one-line comments using //. The coding style doesn't allow it.

[hlandau]

I doubt Unicode is of use to us.

[h-vetinari]

several new data types, including long long int, optional extended integer types, an explicit boolean data type, and a complex type to represent complex numbers:

Bool would be nice and easily polyfilled on platforms which don't have it. Complex probably has poor support and I can't see us needing it. long long we already use.

There's an issue for that (and some preliminary discussion on C99) already in https://github.com/openssl/openssl/issues/17494.

Also, nonstop would be fine with C99 based on this comment.

Sidenote: this PR should probably have "Closes #33" in the OP.

[kroeckx]

It has the closes (fixes) in the commit message.

[kroeckx]

Unicode support is something that can be useful in the apps, but to properly use it we probably also need something like iconv().

[kroeckx]

An alternative could be that we list which C99 features that we require.

[t8m]

An alternative could be that we list which C99 features that we require.

Discussed on OTC meeting 2022-05-24

OTC: We think that this is the only way forward. Approving C99 as a whole does not work for supporting older platforms that we still want to support.

[t8m]

OTC: Kurt, please either call a vote on this or write an alternative proposal.

[t8m]

@kroeckx ping

[t8m]

OTC: vote has not been called. Closing.