[pacman-dev] Use C18 language standard

Message ID 20200326211346.524433-1-anatol.pomozov@gmail.com
State Rejected, archived
Headers show
Series
  • [pacman-dev] Use C18 language standard
Related show

Commit Message

Anatol Pomozov March 26, 2020, 9:13 p.m. UTC
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(-)

Comments

Allan McRae March 27, 2020, 3:47 a.m. UTC | #1
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',
>
Anatol Pomozov March 27, 2020, 7:52 p.m. UTC | #2
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
Allan McRae March 27, 2020, 11:07 p.m. UTC | #3
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
Anatol Pomozov March 31, 2020, 8:12 p.m. UTC | #4
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.
Eli Schwartz March 31, 2020, 8:25 p.m. UTC | #5
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.
Allan McRae April 5, 2020, 8:28 a.m. UTC | #6
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.

Patch

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',