linux-kernel - Re: [PATCH v2 4/6] compiler-gcc.h: add asm

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]

Date:   Fri, 6 Sep 2019 17:13:54 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "gcc-patches@....gnu.org" <gcc-patches@....gnu.org>
Subject: Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool
<segher@...nel.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