Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190829083233.24162-1-linux@rasmusvillemoes.dk>
 <20190830231527.22304-1-linux@rasmusvillemoes.dk> <20190830231527.22304-5-linux@rasmusvillemoes.dk>
 <CAKwvOdktYpMH8WnEQwNE2JJdKn4w0CHv3L=YHkqU2JzQ6Qwkew@mail.gmail.com>
 <a5085133-33da-6c13-6953-d18cbc6ad3f5@rasmusvillemoes.dk> <20190905134535.GP9749@gate.crashing.org>
 <CANiq72nXXBgwKcs36R+uau2o1YypfSFKAYWV2xmcRZgz8LRQww@mail.gmail.com> <20190906122349.GZ9749@gate.crashing.org>
In-Reply-To: <20190906122349.GZ9749@gate.crashing.org>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Fri, 6 Sep 2019 17:13:54 +0200
Message-ID: <CANiq72=3Vz-_6ctEzDQgTA44jmfSn_XZTS8wP1GHgm31Xm8ECw@mail.gmail.com>
Subject: Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition
To:     Segher Boessenkool <segher@kernel.crashing.org>
Cc:     Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Nick Desaulniers <ndesaulniers@google.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> I can't find anything with "feature" and "macros" in the C++ standard,
> it's "predefined macros" there I guess?  In C, it is also "predefined
> macros" in general, and there is "conditional feature macros".

They are introduced in C++20, but they have been added for a lot of
older features in both the language (see [cpp.predefined]p1, around 50
of them) and the library (see [support.limits.general]p3, ~100):

    http://eel.is/c++draft/cpp.predefined#tab:cpp.predefined.ft
    http://eel.is/c++draft/support.limits#tab:support.ft

> Sure.  But the name is traditional, many decades old, it predates glibc.
> Using an established name to mean pretty much the opposite of what it
> normally does is a bit confusing, never mind if that usage makes much
> sense ;-)

Agreed on principle :-) However, I wouldn't say it is the opposite. I
would say they are the same, but from different perspectives: one says
"I want to test if the user enabled the feature", the other says "I
want to test if the vendor implemented the feature". Which is fine,
but for users the meaning is inverted as you say: in the first case
they want to say "I want to enable this feature in this library" --
they don't want to "test" anything. And since most people will be
users, not vendors writing standard libraries, I think the user
perspective would have been better.

Cheers,
Miguel