linux-kernel - Re: [RFC] Use plan9 C extensions

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:   Wed, 9 Jan 2019 15:33:50 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Joel Stanley <joel@....id.au>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [RFC] Use plan9 C extensions

On Wed, Jan 9, 2019 at 12:31 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> While replacing idr_alloc_cyclic(), I've come across a situation in
> which being able to depend on -fplan9-extensions is going to lead to
> nicer code in the users.

Oh, no. Please don't.

The subset of the pla9 extensions that are called just "ms" extenions
is fine. That's a reasonable thing, and is a very natural expansion of
the unnamed structures we already have - namely being able to
pre-declare that unnamed structure/union.

But the full plan9 extensions are nasty, and makes it much too easy to
write "convenient" code that is really hard to read as an outsider
because of how the types are silently converted.

And I think what you want is explicitly that silent conversion.

So no. Don't do it. Use a macro or a inline function that makes the
conversion explicit so that it's shown when grepping.

The "one extra argument" is not a strong argument for something that
simply isn't that common. The upsides of a nonstandard feature like
that needs to be pretty compelling.

We've used various gcc extensions since day #1 ("inline" being perhaps
the biggest one that took _forever_ to become standard C), but these
things need to have very strong arguments.

"One extra argument" that could be hidden by a macro or a helper
inline is simply not a strong argument.

                      Linus