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

Powered by blists - more mailing lists