-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Since C23 bool is keyword #1576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The simplest possible fix for the problem is to specify the used C standard instead of using the compiler default by doing |
@icraggs , I can take this one. Is there a specific version to target? I'm thinking C99? |
@fpagliughi thanks. Yes, C99. I saw that Curl goes for C89 -- I presume you weren't thinking that far back! |
@gerum100 not everyone builds with CMake. I think a source code fix would result in less maintenance in the future. |
C23 adds a number of keywords, and this time they're using some common ones: The quick fix is just tell the compiler to use a specific standard (i.e. C99). I have no problem with this because it's what we've been doing with C++ for years. Originally this was to push the compiler to use a newer standard that the default, like supporting C++11 years back when the compilers were still defaulting to C++98/03. But now it's often used to hold the compiler back as changes are coming at a faster pace; like keeping to C++17 in the face of C++20/23 changes. Anyway, this does cause problems with the headers. If someone wanted to bring C99 headers into an app that wants to use C23, then there are problems. So I think we should release a quick fix for the CMake build ASAP, with notes in the README, saying this can only be built as C99. And then within the next few months get it compatible with C23 using some conditional compilation to only #define the new keywords if we're on an older standard than C23. |
@fpagliughi Why not rename |
@fpagliughi I think it's the right thing to do to set the C level in the CMake config, along with documenting it. It seems that the impact to us here is very limited - only MQTTPacket.h uses the bool definition. I'm happy changing these few uses to unsigned int, or the definition name to boolean, or similar. I just tried this, and that's all I had to do (at least with clang that I used). |
EDIT: I initially thought we had to change the code because the violation was in a header file. But it seems that header is private to the library and not exposed to the applications, so changing the CMake build would suffice to fix this. But, as @icraggs pointed out, the problem is isolated and pretty trivial to fix by updating the source code, so I changed my mind and now recommend fixing the sources to make the code compliant with C23.
@icraggs , you're correct. The only real solution is to take out the typedef from MQTTPacket.h or change it to a name that isn't a keyword. I thought to use |
Should include <stdbool.h> be a solution ? |
I don't think so in this specific situation. In the code it was used in only one internal file to indicate single-bit fields in the structs that formed the wire packets for transfer. Thus it was for a specific one-bit representation of a bool within an integer, not a generic boolean. So the bit representation is important. |
Describe the bug
Since C23
bool
is keyword, sotypedef unsigned int bool;
causes compilation error. This is used inpaho.mqtt.c/src/MQTTPacket.h
Line 31 in 2150ba2
To Reproduce
Expected behavior
Successful compilation.
Log files
Environment (please complete the following information):
Additional context
Debian package downstream bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1097539
The text was updated successfully, but these errors were encountered: