On 29 August 2016 at 21:29, Selva Nair <selva.n...@gmail.com> wrote: > > On Sun, Aug 28, 2016 at 3:46 PM, Steffan Karger <stef...@karger.me> wrote: >> >> On 28 August 2016 at 21:42, Steffan Karger <stef...@karger.me> wrote: >> > 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. >> >> 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..
Yes I'm aware of this. Even so, just compile-time c99 support is valuable in itself. > 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.. That would be my preference too. Definitely c99, maybe __USE_MINGW_ANSI_STDIO__ too. I don't care too much for 50 kB extra in Windows binaries. I'd be much more worried about 50 kB in linux binaries, as that would hurt quite some embedded platforms. -Steffan On 29 August 2016 at 21:29, Selva Nair <selva.n...@gmail.com> wrote: > > On Sun, Aug 28, 2016 at 3:46 PM, Steffan Karger <stef...@karger.me> wrote: >> >> On 28 August 2016 at 21:42, Steffan Karger <stef...@karger.me> wrote: >> > 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. >> >> 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 ------------------------------------------------------------------------------ _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
