Andrew Stitcher created PROTON-2207:
---------------------------------------
Summary: Proton-c clients cannot really be compiled with strict
C89 with gnu compatible compilers
Key: PROTON-2207
URL: https://issues.apache.org/jira/browse/PROTON-2207
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Andrew Stitcher
In testing the 0.31.0rc2 release with clang 10 on fedora 32 I get the following:
{noformat}
In file included from ../c/examples/send-abort.c:22:
In file included from ../c/include/proton/connection.h:26:
In file included from ../c/include/proton/codec.h:26:
../c/include/proton/object.h:206:11: error: '_Bool' is a C99 extension
[-Werror,-Wc99-extensions]
PN_EXTERN bool pn_class_equals(const pn_class_t *clazz, void *a, void *b);
^
/usr/lib64/clang/10.0.0/include/stdbool.h:15:14: note: expanded from macro
'bool'
#define bool _Bool
{noformat}
This is clearly correct in that stdbool.h/_Bool is indeed a C99 feature.
However for non C99 compilers we have some hacks in {{proton/type_compat.h}}
which define bool to be char. Looking at the logic there though the check is to
assume that you should include stdbool if the compiler is C99 or (non ancient)
gcc compatible compiler.
This logic is not correct if you are explicitly compiling the code as C89 which
we do for our example code to ensure that client code could be C89. As the
compiler version will be unchanged even though it no longer should support C99.
This new version of clang is now picking up on the logic failure.
At this point I think the solution is actually to change our base compiler
requirements to be C99. The reason we allow C89 is because Visual Studio didn't
support C99 constructs when the project started. Since VS2013 (Compiler version
18) all the C99 constructs we require are support by Visual Studio too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
