ITNOA
As you can see many defects resolve in [C17](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2244.htm) and [C23](https://en.wikipedia.org/wiki/C23_(C_standard_revision) introduce many new language features for clean coding.
So I suggest migrate codebase to C23, and if you agree with me, I can try to migrate that
RHEL9 : gcc 11.x in app stream RHEL8 : gcc 8.x or gcc 9.x in app stream.
Ubuntu 20.04: gcc 9.x Ubuntu 24.04: gcc 13.x
[compiler support](https://en.cppreference.com/w/c/compiler_support)
We are right now on version C11. The proposed C23 version is not supported from the compilers in Ubuntu 20.04 and also RHEL9. There are several features which are also still only supported partially from gcc 13.x, according to your list. So it makes no sense to update to the standard version C23 at this point in time.
@henningw thanks for responding
as you can see some minor features of C23 supports in gcc 9.x and much more in gcc 11.x, but if we want to stay friendly with 20.04, I suggest upgrading at last to C17 (for resolving many defects in C11) https://web.archive.org/web/20181230041359/http://www.open-std.org/jtc1/sc22...
I agree that using C17 would be indeed better due to the many bugfixes. We are currently not using any C11 features, I think, it was just introduced as part of the cmake switch. So I would propose that we are doing the C17 change after 6.0 was released, that gives it also one more year of compiler support. Some of the standardized atomic functions would be interesting to use for example in the core.
So, Can I update PR?
@henningw I want to use C17 features in my kamailio module :)
Migrating to new C version does not cause major version change? That's why I'm asking if it's necessary to do this during the migration to version 6.
The 6.1 release will be also considered a major release. Minor releases are from 5.8.3 to 5.8.4.
Ok, thanks :)
[@henningw](https://github.com/henningw) I want to use C17 features in my kamailio module :)
I think you can create a new module with whatever standard you want if you set the standard in it's own module `CMakeLists.txt`. CMake will respect the standard set only for that module and whatever is included in that file.
Bear in mind though, that the compiler used must support the version, and if you want it packaged, we are using the OS package-distributed `gcc` or `clang` that might or might not support it fully on that OS version.
Enforcing the C version in a module should be fine and based on @xkaraman comment is possible, but in core and main (and most of old) modules should not be done till common distros have their supported versions phased out for a while.
C17 was published in 2018, it took some time to implement it and there are several common distros with extended support not having it supported by the default compiler version.
github-actions[bot] left a comment (kamailio/kamailio#4106)
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #4106 as not planned.
-
Daniel-Constantin Mierla -
github-actions[bot]
-
Henning Westerholt
-
soroshsabz
-
Xenofon Karamanos