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

This is Matthew's example tweaked a little bit for my understanding, FWIW:
https://godbolt.org/z/mD7HdX

On Wed, Jan 9, 2019 at 3:34 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

I agree that this reminds me of an implicit conversion, which is one
of the *worst* parts of C IMO.  Implicit conversions violate the
principle of least surprise
(https://en.wikipedia.org/wiki/Principle_of_least_astonishment), and
implicit conversions are the most pointed to "defect" in languages
like JavaScript.  I understand why they're convenient, but the
resulting surprising bugs don't outweigh their cost (again, my
opinion), and developers frequently can't keep these implicit
conversion rules straight (whether we're talking about JavaScript or
C).  When it comes to type conversions, my personal thoughts align
with the Zen of Python ("Explicit is better than implicit.").

Of course, each code base can weigh the benefits with the risks and
decide what works best for them.

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

I agree that something like builtin_types_compatible_p() in a macro
could help make these functions more "generic" in the sense of being
able to accept either a `struct xarray*` or `struct xarray_cyclic*`.

We're always happy to see where Clang is in terms of GCC
compatibility; I'm always happy to chat about this subject more in the
future. (and TIL about -fplan9-extensions) :D
-- 
Thanks,
~Nick Desaulniers