linux-kernel - Re: [PATCH] Kbuild: remove -std=gnu89 from compiler arguments

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3Lv_uSXt9yf-9iOV3hZgV7KvwZjL-gbLTLRgo0UOQguw@mail.gmail.com>
Date:   Mon, 28 Feb 2022 09:07:03 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Masahiro Yamada <masahiroy@...nel.org>, llvm@...ts.linux.dev,
        Jonathan Corbet <corbet@....net>,
        Federico Vaga <federico.vaga@...a.pv.it>,
        Alex Shi <alexs@...nel.org>, Hu Haowen <src.res@...il.cn>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-doc-tw-discuss@...ts.sourceforge.net,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        intel-gfx <intel-gfx@...ts.freedesktop.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        greybus-dev@...ts.linaro.org, linux-staging@...ts.linux.dev,
        linux-btrfs <linux-btrfs@...r.kernel.org>
Subject: Re: [PATCH] Kbuild: remove -std=gnu89 from compiler arguments

On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> And I don't want somebody with a newer compiler version to not notice
> that he or she ended up using a c17 feature, just because _that_
> compiler supported it, and then other people get build errors because
> their compilers use gnu11 instead by default.
>
> Put another way: I see absolutely no upside to allowing different
> users using higher/lower versions of the standard. There are only
> downsides.
>
> If gnu11 is supported by gcc-5.1 and up, and all the relevant clang
> versions, then let's just pick that.

Ok, changed my patch to -gnu11 now.

> And if there are any possible future advantages to gnu17 (or eventual
> gnu2x versions), let's document those, so that we can say "once our
> compiler version requirements go up sufficiently, we'll move to gnuXX
> because we want to take advantage of YY".
>
> Please?

I think all of the options here are equally bad: picking gnu11 means
we use a non-standard default for anything other than gcc-5 and
may get surprised again in the future when we want to change to
a newer version; -std=gnu1x would work as an alias for gnu17 in
all versions including gcc-5 but is already marked as 'deprecated'
in the gcc documentation; and using -std=gnu17 for modern compilers
requires a workaround for gcc-7 and earlier.

Regarding new features from gcc-2x, I think we already use
most of what is listed in https://en.wikipedia.org/wiki/C2x, as
those are all GNU extensions that are valid in modern gnu89 as
well. Newly added features seem to only depend on the compiler
version, e.g. #elifdef works in both clang-13 and gcc-12 with
any -std=gnu?? argument, so picking an earlier standard won't
stop people from breaking the build with older compilers.

         Arnd