[pacman-dev] [PATCH] Use C18 language standard
C18 is the latest released version of the language spec. The toolchains support it starting with GCC 8.1.0 and Clang 7. Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> --- configure.ac | 2 +- meson.build | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 9db39232..84869ce5 100644 --- a/configure.ac +++ b/configure.ac @@ -183,7 +183,7 @@ AC_SUBST(LFS_CFLAGS) # Checks for programs. AC_PROG_AWK -AC_PROG_CC_C99 +AC_PROG_CC_C18 AC_PROG_INSTALL AC_CHECK_PROGS([PYTHON], [python3 python], [false]) AC_PATH_PROGS([BASH_SHELL], [bash bash4], [false]) diff --git a/meson.build b/meson.build index fc81fa27..2f4e7cc4 100644 --- a/meson.build +++ b/meson.build @@ -3,7 +3,7 @@ project('pacman', version : '5.2.1', license : 'GPLv2+', default_options : [ - 'c_std=gnu99', + 'c_std=c18', 'prefix=/usr', 'sysconfdir=/etc', 'localstatedir=/var', -- 2.26.0
On 27/3/20 7:13 am, Anatol Pomozov wrote:
C18 is the latest released version of the language spec. The toolchains support it starting with GCC 8.1.0 and Clang 7.
GCC 8.1.0 - May 2, 2018 Clang 7 - 19 September 2018 So available for 18 months. Seems reasonable given the next release is a few months out minimum. But why do we need this version? What feature will be used? Is C11 enough?
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> --- configure.ac | 2 +- meson.build | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac index 9db39232..84869ce5 100644 --- a/configure.ac +++ b/configure.ac @@ -183,7 +183,7 @@ AC_SUBST(LFS_CFLAGS)
# Checks for programs. AC_PROG_AWK -AC_PROG_CC_C99 +AC_PROG_CC_C18 AC_PROG_INSTALL AC_CHECK_PROGS([PYTHON], [python3 python], [false]) AC_PATH_PROGS([BASH_SHELL], [bash bash4], [false]) diff --git a/meson.build b/meson.build index fc81fa27..2f4e7cc4 100644 --- a/meson.build +++ b/meson.build @@ -3,7 +3,7 @@ project('pacman', version : '5.2.1', license : 'GPLv2+', default_options : [ - 'c_std=gnu99', + 'c_std=c18', 'prefix=/usr', 'sysconfdir=/etc', 'localstatedir=/var',
Hey On Thu, Mar 26, 2020 at 8:47 PM Allan McRae <allan@archlinux.org> wrote:
On 27/3/20 7:13 am, Anatol Pomozov wrote:
C18 is the latest released version of the language spec. The toolchains support it starting with GCC 8.1.0 and Clang 7.
GCC 8.1.0 - May 2, 2018 Clang 7 - 19 September 2018
So available for 18 months. Seems reasonable given the next release is a few months out minimum.
But why do we need this version? What feature will be used? Is C11 enough?
C18 is mostly a clarification on top of C11 language spec. C18 does not introduce any new language features http://www.iso-9899.info/wiki/The_Standard#C18 C11 is what was a big step for C language. I use C11 feature in my other projects and I really like it. Some of my favorite features are: - type-generic expressions. This is a poor-man generic that can be used in macros. Quite useful in some cases for example instead of having htobe16/htobe32/htobe64/.. this feature allows to have a macro htobe() with functionality that depends on the parameter type. - _Thread_local specifier that allows to introduce a thread-local variables - defines for atomic types + functions for accessing the vars in atomic way
On 28/3/20 5:52 am, Anatol Pomozov wrote:
Hey
On Thu, Mar 26, 2020 at 8:47 PM Allan McRae <allan@archlinux.org> wrote:
On 27/3/20 7:13 am, Anatol Pomozov wrote:
C18 is the latest released version of the language spec. The toolchains support it starting with GCC 8.1.0 and Clang 7.
GCC 8.1.0 - May 2, 2018 Clang 7 - 19 September 2018
So available for 18 months. Seems reasonable given the next release is a few months out minimum.
But why do we need this version? What feature will be used? Is C11 enough?
C18 is mostly a clarification on top of C11 language spec. C18 does not introduce any new language features http://www.iso-9899.info/wiki/The_Standard#C18
Hence why do we need that. Every newer bit of software we require limits where pacman can be built.
C11 is what was a big step for C language. I use C11 feature in my other projects and I really like it. Some of my favorite features are: - type-generic expressions. This is a poor-man generic that can be used in macros. Quite useful in some cases for example instead of having htobe16/htobe32/htobe64/.. this feature allows to have a macro htobe() with functionality that depends on the parameter type. - _Thread_local specifier that allows to introduce a thread-local variables - defines for atomic types + functions for accessing the vars in atomic way
I don't need to know what is in the standard. What features do you plan to use in the pacman code base and where? A
Hi On Fri, Mar 27, 2020 at 4:08 PM Allan McRae <allan@archlinux.org> wrote:
On 28/3/20 5:52 am, Anatol Pomozov wrote:
Hey
On Thu, Mar 26, 2020 at 8:47 PM Allan McRae <allan@archlinux.org> wrote:
On 27/3/20 7:13 am, Anatol Pomozov wrote:
C18 is the latest released version of the language spec. The toolchains support it starting with GCC 8.1.0 and Clang 7.
GCC 8.1.0 - May 2, 2018 Clang 7 - 19 September 2018
So available for 18 months. Seems reasonable given the next release is a few months out minimum.
But why do we need this version? What feature will be used? Is C11 enough?
C18 is mostly a clarification on top of C11 language spec. C18 does not introduce any new language features http://www.iso-9899.info/wiki/The_Standard#C18
Hence why do we need that. Every newer bit of software we require limits where pacman can be built.
C18 is the latest stable specification of the language that is supported by modern toolchains. It sounds reasonable to me if pacman keeps up with the technology stack and uses its advancements. Are you saying that C18 requirement introduces limits due to requirement of this 2 years old toolchains? Just curious what platforms where pacman is used lacks these toolchains?
C11 is what was a big step for C language. I use C11 feature in my other projects and I really like it. Some of my favorite features are: - type-generic expressions. This is a poor-man generic that can be used in macros. Quite useful in some cases for example instead of having htobe16/htobe32/htobe64/.. this feature allows to have a macro htobe() with functionality that depends on the parameter type. - _Thread_local specifier that allows to introduce a thread-local variables - defines for atomic types + functions for accessing the vars in atomic way
I don't need to know what is in the standard. What features do you plan to use in the pacman code base and where?
It is not really required to use all the spec features right away. But having an option to use it in the future is gonna be useful. As of particular use case - if in the future we decide to speed-up the installation with more thread-level parallelism (e.g. checking signatures/unpacking/... on multiple CPUs) then better C11 mutlithreadding support is very useful.
On 3/31/20 4:12 PM, Anatol Pomozov wrote:
C18 is the latest stable specification of the language that is supported by modern toolchains. It sounds reasonable to me if pacman keeps up with the technology stack and uses its advancements.
What advancements are used as a direct result of passing -std=c11? What generated object code does this patch *on its own*, change?
Are you saying that C18 requirement introduces limits due to requirement of this 2 years old toolchains? Just curious what platforms where pacman is used lacks these toolchains?
The limit it introduces is "over-specifying requirements".
It is not really required to use all the spec features right away. But having an option to use it in the future is gonna be useful.
As of particular use case - if in the future we decide to speed-up the installation with more thread-level parallelism (e.g. checking signatures/unpacking/... on multiple CPUs) then better C11 mutlithreadding support is very useful.
If we need it in the future, we can add it in the future. Am I missing something? If I add a new pacman feature that relies on libfoo.so, I add a dependency on libfoo.so -- but does that mean I submit a patch the year before, to "pass -lfoo when building pacman, to make the libfoo library an option since it will be useful in the future"? No, I submit a patch that introduces the use of libfoo functions, and in the same patch, I add -lfoo to the build flags. So, it seems reasonable to wait until we want to add c11 features to pacman, and then submit a patch with the new features, and bump the minimum-required-language-version argument at the same time. -- Eli Schwartz Bug Wrangler and Trusted User
On 1/4/20 6:25 am, Eli Schwartz wrote:
On 3/31/20 4:12 PM, Anatol Pomozov wrote:
C18 is the latest stable specification of the language that is supported by modern toolchains. It sounds reasonable to me if pacman keeps up with the technology stack and uses its advancements.
What advancements are used as a direct result of passing -std=c11? What generated object code does this patch *on its own*, change?
Are you saying that C18 requirement introduces limits due to requirement of this 2 years old toolchains? Just curious what platforms where pacman is used lacks these toolchains?
The limit it introduces is "over-specifying requirements".
It is not really required to use all the spec features right away. But having an option to use it in the future is gonna be useful.
As of particular use case - if in the future we decide to speed-up the installation with more thread-level parallelism (e.g. checking signatures/unpacking/... on multiple CPUs) then better C11 mutlithreadding support is very useful.
If we need it in the future, we can add it in the future. Am I missing something?
If I add a new pacman feature that relies on libfoo.so, I add a dependency on libfoo.so -- but does that mean I submit a patch the year before, to "pass -lfoo when building pacman, to make the libfoo library an option since it will be useful in the future"? No, I submit a patch that introduces the use of libfoo functions, and in the same patch, I add -lfoo to the build flags.
So, it seems reasonable to wait until we want to add c11 features to pacman, and then submit a patch with the new features, and bump the minimum-required-language-version argument at the same time.
Also... configure.ac:186: error: possibly undefined macro: AC_PROG_CC_C18 If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
participants (3)
-
Allan McRae
-
Anatol Pomozov
-
Eli Schwartz