Drop gnu89/c89 support, switch to c99

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less readable code, for example by forcing all declaration to be at the starting of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

Quoted 2 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might

even

Quoted 3 lines

differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that

MSVC

Quoted 3 lines

didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write

less

Quoted 1 line

readable code, for example by forcing all declaration to be at the

starting

Quoted 4 lines

of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

To be clear: I'm aware we never really decided to switch to c99, so this patch is partly meant to start discussion. Anyone who cares for gnu89 support, please speak up :)

Quoted 18 lines · Steffan Karger

Quoted 16 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults
to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even
differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC
didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less
readable code, for example by forcing all declaration to be at the starting
of a block (which includes 'for loop initial declarations').

Quoted 6 lines

Quoted 2 lines

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

To be clear: I'm aware we never really decided to switch to c99, so this patch is partly meant to start discussion. Anyone who cares for gnu89 support, please speak up :)

I have been all along wishing for this switch to C99 and the demise of dated MSVC support. But we also have to keep in mind that mingw-w64 (and mingw) targets a least common denominator of Windows runtime (runtime version 6.0 ?). That is not going to change as the very spirit of mingw is to make executables that run with stock windows libraries. That means features of C99 requiring run-time support (stdio is an example) cannot be supported by mingw by default as it requires statically linking in additional code.

For example, __USE_MINGW_ANSI_STDIO has to be defined to support some of the printf format specs and that adds about 50K to the binary. That also invalidates windows-specific format specifiers such as %I64u which is used in a couple places in the code. Last time I suggested this Gert was opposed to it on grounds of the extra define, need for code changes, increased binary size etc..

My personal preference: go for -std=c99, add the above define for mingw and get rid of %I64.. (a only a couple of instances). That said, I do not know how complete is the C99 support in mingw-w64, and whether there are other issues that need work around. I suppose we can handle them, if any, as they come..

Quoted 18 lines · Steffan Karger

Quoted 16 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults
to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even
differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC
didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less
readable code, for example by forcing all declaration to be at the starting
of a block (which includes 'for loop initial declarations').

Quoted 6 lines

Quoted 2 lines

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

To be clear: I'm aware we never really decided to switch to c99, so this patch is partly meant to start discussion. Anyone who cares for gnu89 support, please speak up :)

I have been all along wishing for this switch to C99 and the demise of dated MSVC support. But we also have to keep in mind that mingw-w64 (and mingw) targets a least common denominator of Windows runtime (runtime version 6.0 ?). That is not going to change as the very spirit of mingw is to make executables that run with stock windows libraries. That means features of C99 requiring run-time support (stdio is an example) cannot be supported by mingw by default as it requires statically linking in additional code.

For example, __USE_MINGW_ANSI_STDIO has to be defined to support some of the printf format specs and that adds about 50K to the binary. That also invalidates windows-specific format specifiers such as %I64u which is used in a couple places in the code. Last time I suggested this Gert was opposed to it on grounds of the extra define, need for code changes, increased binary size etc..

My personal preference: go for -std=c99, add the above define for mingw and get rid of %I64.. (a only a couple of instances). That said, I do not know how complete is the C99 support in mingw-w64, and whether there are other issues that need work around. I suppose we can handle them, if any, as they come..

Selva

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less readable code, for example by forcing all declaration to be at the starting of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

Signed-off-by Steffan Karger <[email protected]...> --- configure.ac

| 1 + 1 file changed, 1 insertion(+)

configure.ac index 9189c94..16cab19 renamed from configure.ac +0 -0

100644 --- a/configure.ac +++ b/configure.ac @@ -1125,6 +1125,7 @@ if test "${enable_pkcs11}" = "yes"; then ) fi

+CFLAGS="${CFLAGS} -std=c99" if test "${enable_pedantic}" = "yes"; then enable_strict="yes" CFLAGS="${CFLAGS} -pedantic"

Quoted 24 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less readable code, for example by forcing all declaration to be at the starting of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

Signed-off-by Steffan Karger <[email protected]...> ---

configure.ac | 1 + 1 file changed, 1 insertion(+)

configure.ac index 9189c94..16cab19 renamed from configure.ac +0 -0

100644 --- a/configure.ac +++ b/configure.ac @@ -1125,6 +1125,7 @@ if test "${enable_pkcs11}" = "yes"; then ) fi

Quoted 2 lines

+CFLAGS="${CFLAGS} -std=c99" if test "${enable_pedantic}" = "yes"; then enable_strict="yes" CFLAGS="${CFLAGS} -pedantic"

I so much wants to give this an ACK. But this breaks CentOS 5 builds very badly. The glibc-headers isn't prepared for C99 on that distro.

I took the latest git master where I could do a successful build. Then I applied just this patch, and here is the explosion:
<http://paste.fedoraproject.org/417049/14725031/>

To move towards C99, we need to add some tricks which makes this not requiring users to overwrite C99 with C89. That should happen automatically.

Some CentOS 5.11 details: glibc-2.5-123.el5_11.3
glibc-headers-2.5-123.el5_11.3 gcc-4.1.2-55.el5
openssl-0.9.8e-40.el5_11 lzo-2.02-2.el5.1

Quoted 37 lines · David Sommerseth

Quoted 24 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less readable code, for example by forcing all declaration to be at the starting of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

Signed-off-by Steffan Karger <[email protected]...> ---

configure.ac | 1 + 1 file changed, 1 insertion(+)

configure.ac index 9189c94..16cab19 renamed from configure.ac +0 -0

100644 --- a/configure.ac +++ b/configure.ac @@ -1125,6 +1125,7 @@ if test "${enable_pkcs11}" = "yes"; then ) fi

Quoted 2 lines

+CFLAGS="${CFLAGS} -std=c99" if test "${enable_pedantic}" = "yes"; then enable_strict="yes" CFLAGS="${CFLAGS} -pedantic"

I so much wants to give this an ACK. But this breaks CentOS 5 builds very badly. The glibc-headers isn't prepared for C99 on that distro.

I took the latest git master where I could do a successful build. Then I applied just this patch, and here is the explosion:
<http://paste.fedoraproject.org/417049/14725031/>

Quoted 7 lines

To move towards C99, we need to add some tricks which makes this not requiring users to overwrite C99 with C89. That should happen automatically.

Some CentOS 5.11 details: glibc-2.5-123.el5_11.3
glibc-headers-2.5-123.el5_11.3 gcc-4.1.2-55.el5
openssl-0.9.8e-40.el5_11 lzo-2.02-2.el5.1

Did a bit more testing.

-std=gnu89, -std=gnu99
Works very fine (compiles without errors).

-std=c99
Makes glibc-headers explode, as already described

-std=c89
Makes the LZ4 library we're shipping explode.

HI,

Quoted 54 lines · David Sommerseth

Quoted 38 lines · David Sommerseth

Quoted 25 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less readable code, for example by forcing all declaration to be at the starting of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

Signed-off-by Steffan Karger <[email protected]...> ---

configure.ac | 1 + 1 file changed, 1 insertion(+)

configure.ac index renamed from configure.ac +0 -0

9189c94..16cab19 100644 --- a/configure.ac +++ b/configure.ac

configure.ac index renamed from configure.ac +0 -0

@@ -1125,6 +1125,7 @@ if test "${enable_pkcs11}" = "yes";

then ) fi

Quoted 2 lines

+CFLAGS="${CFLAGS} -std=c99" if test "${enable_pedantic}" = "yes"; then enable_strict="yes" CFLAGS="${CFLAGS} -pedantic"

I so much wants to give this an ACK. But this breaks CentOS 5 builds very badly. The glibc-headers isn't prepared for C99 on that distro.

I took the latest git master where I could do a successful build. Then I applied just this patch, and here is the
explosion: <http://paste.fedoraproject.org/417049/14725031/>

Quoted 7 lines

To move towards C99, we need to add some tricks which makes this not requiring users to overwrite C99 with C89. That should happen automatically.

Some CentOS 5.11 details: glibc-2.5-123.el5_11.3
glibc-headers-2.5-123.el5_11.3 gcc-4.1.2-55.el5
openssl-0.9.8e-40.el5_11 lzo-2.02-2.el5.1

Did a bit more testing.

-std=gnu89, -std=gnu99 Works very fine (compiles without errors).

-std=c99 Makes glibc-headers explode, as already described

Quoted 1 line

-std=c89 Makes the LZ4 library we're shipping explode.

Hm, that's too bad. But I think we should still go for c99, rather than gnu99. That should actually result in *more* portable code on our side. The CentOS package maintainer can then easily patch configure.ac (or configure) to use gnu99 for arcane platforms.

Quoted 59 lines · Steffan Karger

HI,

Quoted 55 lines · David Sommerseth

Quoted 39 lines · David Sommerseth

Quoted 25 lines · Steffan Karger

Previously, we would use the compiler's default C version, which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and c11 for clang, but might even differ per distro.

One of the reasons to accept the gnu89 default of GCC < 4.9, was that MSVC didn't support c99. But in MSVC 2015, MS finanally fixed that.

Having to support c89 in the codebase occasionally forces us to write less readable code, for example by forcing all declaration to be at the starting of a block (which includes 'for loop initial declarations').

Let's be clear about what standard we obey, and stop punishing ourselves with c89/gnu89. Let's switch the master branch to c99.

Signed-off-by Steffan Karger <[email protected]...> ---

configure.ac | 1 + 1 file changed, 1 insertion(+)

configure.ac index renamed from configure.ac +0 -0

9189c94..16cab19 100644 --- a/configure.ac +++ b/configure.ac @@ -1125,6 +1125,7 @@ if test "${enable_pkcs11}" = "yes"; then ) fi

configure.ac index

Quoted 3 lines

configure.ac index renamed from configure.ac +1 -1

+CFLAGS="${CFLAGS} -std=c99" if test "${enable_pedantic}" =
 "yes"; then enable_strict="yes" CFLAGS="${CFLAGS}
-pedantic"

I so much wants to give this an ACK. But this breaks CentOS 5 builds very badly. The glibc-headers isn't prepared for C99 on that distro.

I took the latest git master where I could do a successful build. Then I applied just this patch, and here is the
explosion: <http://paste.fedoraproject.org/417049/14725031/>

Quoted 7 lines

To move towards C99, we need to add some tricks which makes this not requiring users to overwrite C99 with C89. That should happen automatically.

Some CentOS 5.11 details: glibc-2.5-123.el5_11.3 glibc-headers-2.5-123.el5_11.3 gcc-4.1.2-55.el5 openssl-0.9.8e-40.el5_11 lzo-2.02-2.el5.1

Did a bit more testing.

-std=gnu89, -std=gnu99 Works very fine (compiles without errors).

-std=c99 Makes glibc-headers explode, as already described

Quoted 7 lines

Quoted 1 line

-std=c89 Makes the LZ4 library we're shipping explode.

Hm, that's too bad. But I think we should still go for c99, rather than gnu99. That should actually result in *more* portable code on our side. The CentOS package maintainer can then easily patch configure.ac (or configure) to use gnu99 for arcane platforms.

For the stock CentOS 5 package, it probably won't matter. That's indirectly maintained by Red Hat doing all kind of backports whenever needed.

For the Fedora EPEL releases (which keeps our release cycles fairly tight), I'm adding Jon to this discussion directly as the main Fedora package maintainer for OpenVPN.

Any thoughts on this, Jon?

[…]

Just some more benchmarks. I just compiled successfully with -std=c99 on an old Scientific Linux 6.5 (RHEL 6.5 clone) I found. Another important detail, RHEL5 will reach the "End of Production" phase March 2017, OpenVPN have generally stopped supporting the oldest RHEL releases once it hits EOL. RHEL 5 subscribers may purchase an extended life cycle, but we have not cared too much about that so far.

[…]

Just some more benchmarks. I just compiled successfully with -std=c99 on an old Scientific Linux 6.5 (RHEL 6.5 clone) I found. Another important detail, RHEL5 will reach the "End of Production" phase March 2017, OpenVPN have generally stopped supporting the oldest RHEL releases once it hits EOL. RHEL 5 subscribers may purchase an extended life cycle, but we have not cared too much about that so far.

There is one detail though regarding the patch itself. Your patch adds -std=c99 to the CFLAGS quite early. The compile line gets quite interesting if you try to swap this setting by using the recommended approach:

   ./configure CFLAGS="$CFLAGS -std=gnu89"

Doing this results in the command line being run during compilation to be be: gcc -std=gnu89 .... -std=c99 ...

So the -std argument appears twice. This should probably be avoided.

-std=c89
Makes the LZ4 library we're shipping explode.