Configurable C standard #6911
Configurable C standard #6911
Conversation
This PR ensures and enforces C90 conformance for all files C, including tests. * Modify CMakeLists.txt to mandate C90 conformance (for better compiler compatibility) * Update deps/ntlmclient/utf8.h to latest version * Modify two tests and one header to use C comments instead of C++ comments
Users can now set up cmake with -DC_STANDARD=... or -DC_EXTENSIONS=... We default to C90 with C_EXTENSIONS=OFF, but callers can override if they desire.
The memory sanitizer builds are special snowflakes; let them be c90 with extensions.
34484b2 to
d6a1107
Compare
| - `C_STANDARD`: the C standard to compile against; defaults to `C90` | ||
| - `C_EXTENSIONS`: whether compiler extensions are supported; defaults to `OFF` |
There was a problem hiding this comment.
Is there a particular reason to not leverage the standard cmake variables?
https://cmake.org/cmake/help/latest/variable/CMAKE_C_STANDARD.html
https://cmake.org/cmake/help/latest/variable/CMAKE_C_EXTENSIONS.html
There was a problem hiding this comment.
😔 Not knowing about it, mostly. Does this solve the problem in a superior way?
There was a problem hiding this comment.
Well, "standard" means it is already known and/or easy to discover.
It is referenced in the documentation of the target properties, for determining the default value.
It would nicely complement the use of other standard variables (CMAKE_C_FLAGS).
And the standard pattern to provide default values for an input variable is to use cache variables and options. This can be discovered by CMake GUIs.
set(CMAKE_C_STANDARD "90" CACHE STRING "The C standard to compile against")
option(CMAKE_C_EXTENSIONS "Whether compiler extensions are supported" "OFF")
There was a problem hiding this comment.
Sure I understand what you're saying, but does it actually work for us given that we have deps that may have a variety of other cstd compliance levels? In other words does it apply to the whole of the system?
With this PR, we apply the cstd level just to our projects. I guess we could use this standard feature as the default and then make the deps specify their compliance levels individually. Or, I suppose, just let them error.
There was a problem hiding this comment.
does it apply to the whole of the system?
Yes.
does it actually work for us given that we have deps that may have a variety of other cstd compliance levels?
I can't answer that. I arrived here from package manager which de-vendors deps, so they are isolated from this setting.
But the reason I did ask is similar, only the other way: libgit2 might also be used a subproject, inheriting top-level settings.
So no change requested.
FTR the vcpkg port carries a patch to set the standard to 99, with the comment "for 'inline' in system headers". The patch can go away with the new change. But 90 isn't the right standard when it comes to Android (#6574). Maybe what I really want is libgit2 to generally chose 99 for Android instead of requiring users to make that override.
There was a problem hiding this comment.
I think that your advice is good, see #6914.
Do you think that we should default to 99 on Android? 🤔
There was a problem hiding this comment.
Why not?
At least this is the current patch in vcpkg, building in CI with NDK r26, API level 21.
Even if there were Android users with another toolchain: would they be hurt with the default being 99?
Make c standard configurable; defaulting to an extension-free c90