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...
That being said, here's a proposal:
-----
Subject: Make cert_data.h and test_cryptoapi/pkcs11.c C99 compliant
...to fix compilation on MSVC 2143 <insert actual version and relevant C
language settings here>:
- Do not use non-literal initializers for static objects
- Replace empty initializer {} by {0}
> Signed-off-by: Selva Nair <selva.n...@gmail.com>
-----
I was not getting rid of any defines -- just trying to avoid defines
if it can be done without jumping through too many hoops. Right,
(key1) would be better.
Instead of making key2 local, we can write it out fully without
referring to the fact that key1 = key2. The latter was anyway a lazy
man's choice, not relevant for the working of the tests.
If anyone feels strongly I can submit a v2 with key2, key4, and cname4
fully written out like:
That is not what I am proposing, redundance in source code is not a
valid "fix" or approach... -> [1]
It's just... I have been writing too much C++14 or C++17 code lately (on
MSVC 2015, 2017, 2022 and with MS Build Tools 2019 because that was the
customer's newest-limit) to want to mess with C limitations that serve
their purpose on paper, but are getting in the way in practice. Of
course then you have discussions about C++ linkage (the only reasonable
solution is "avoid"), exceptions (serious discussion what and where) and
about contributors. I am aware C++ is abhorred by some but I usually
find they set their minds in the first decade of the millennium,
literally before C++11, but that would also be the side door to sneak it
in because people who believe their strange OS doesn't have a C++
compiler can still compile OpenVPN proper, just not unit tests.
That may also make maintaining this data easier -- ie., any cert/key
pair could be replaced without affecting others.
[1] So I would go the pragmatic way here and just change once there is
really a need to replace certificates. It's only a test after all.
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
