Am 28.03.23 um 10:47 schrieb Frank Lichtenheld:
On Mon, Mar 27, 2023 at 09:45:53PM +0200, Matthias Andree wrote:
Am 27.03.23 um 16:45 schrieb Selva Nair:
Hi,

On Mon, Mar 27, 2023 at 9:59 AM Matthias Andree
<matthias.and...@gmx.de> wrote:

     Am 27.03.23 um 13:49 schrieb selva.n...@gmail.com:
     > From: Selva Nair <selva.n...@gmail.com>
     >
     > - Do not use non-literal initializers for static objects
     > - Replace empty initializer {} by {0}

     Should we go to a revision, I would suggest to not make something
     compliant to a compiler because that is assigning it way too much
     power
     and control. A terms such as "ready to be compiled with MSVC" or so
     would be in order, or making this code compliant with some wisely
     chosen
     version of the ISO 9899 standard, aka. standard C.


In this case "MSVC compliant" was arguably a poor choice of words as
what the change does is to avoid non-C99 constructs. However it made
sense to refer to MSVC in the context of what prompted this patch.

That said, in a cross-platform code base one often has to make changes
to please compilers just to get things to build.

I don't mind what we're doing here... just that I want to avoid the
impression as though MSVC were setting the standards. There's always
MinGW-GCC...

GCC doesn't seem to care about any of this. Which doesn't really make
it easier to write code that adheres to standards.

Which is why it might be the easy route to a Windows executable.  As
long as the calling convention matches and there are no by-extension
exceptions, even GCC and Windows objects should mix.

OTOH I share the pain that I have yet to find that "disallow all
extensions" switch, for portability checks.  -pedantic-errors -std=c99
is going some way, but apparently not all the way.  clang may be a bit
pickier, and it will be really complaining about missing prototypes.

It's still compliance with language standards though, not with compilers.


_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to