linux-kernel - Re: [PATCH v12 05/18] kunit: test: add the concept of expectations

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]

Message-Id: <20190813050206.2A49C206C2@mail.kernel.org>
Date:   Mon, 12 Aug 2019 22:02:05 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Brendan Higgins <brendanhiggins@...gle.com>
Cc:     frowand.list@...il.com, gregkh@...uxfoundation.org,
        jpoimboe@...hat.com, keescook@...gle.com,
        kieran.bingham@...asonboard.com, mcgrof@...nel.org,
        peterz@...radead.org, robh@...nel.org, shuah@...nel.org,
        tytso@....edu, yamada.masahiro@...ionext.com,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        kunit-dev@...glegroups.com, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-nvdimm@...ts.01.org, linux-um@...ts.infradead.org,
        Alexander.Levin@...rosoft.com, Tim.Bird@...y.com,
        amir73il@...il.com, dan.carpenter@...cle.com, daniel@...ll.ch,
        jdike@...toit.com, joel@....id.au, julia.lawall@...6.fr,
        khilman@...libre.com, knut.omang@...cle.com, logang@...tatee.com,
        mpe@...erman.id.au, pmladek@...e.com, rdunlap@...radead.org,
        richard@....at, rientjes@...gle.com, rostedt@...dmis.org,
        wfg@...ux.intel.com
Subject: Re: [PATCH v12 05/18] kunit: test: add the concept of expectations

Quoting Brendan Higgins (2019-08-12 17:33:52)
> On Mon, Aug 12, 2019 at 04:57:00PM -0700, Stephen Boyd wrote:
> > Quoting Brendan Higgins (2019-08-12 11:24:08)
> > > + */
> > > +#define KUNIT_EXPECT_TRUE(test, condition) \
> > > +               KUNIT_TRUE_ASSERTION(test, KUNIT_EXPECTATION, condition)
> > 
> > A lot of these macros seem double indented.
> 
> In a case you pointed out in the preceding patch, I was just keeping the
> arguments column aligned.
> 
> In this case I am just indenting two tabs for a line continuation. I
> thought I found other instances in the kernel that did this early on
> (and that's also what the Linux kernel vim plugin wanted me to do).
> After a couple of spot checks, it seems like one tab for this kind of
> line continuation seems more common. I personally don't feel strongly
> about any particular version. I just want to know now what the correct
> indentation is for macros before I go through and change them all.
> 
> I think there are three cases:
> 
> #define macro0(param0, param1) \
>                 a_really_long_macro(...)
> 
> In this first case, I use two tabs for the first indent, I think you are
> telling me this should be one tab.

Yes. Should be one.

> 
> #define macro1(param0, param1) {                                               \
>         statement_in_a_block0;                                                 \
>         statement_in_a_block1;                                                 \
>         ...                                                                    \
> }
> 
> In this case, every line is in a block and is indented as it would be in
> a function body. I think you are okay with this, and now that I am
> thinking about it, what I think you are proposing for macro0 will make
> these two cases more consistent.
> 
> #define macro2(param0,                                                         \
>                param1,                                                         \
>                param2,                                                         \
>                param3,                                                         \
>                ...,                                                            \
>                paramn) ...                                                     \
> 
> In this last case, the body would be indented as in macro0, or macro1,
> but the parameters passed into the macro are column aligned, consistent
> with one of the acceptable ways of formatting function parameters that
> don't fit on a single line.
> 
> In all cases, I put 1 space in between the closing parameter paren and
> the line continuation `\`, if only one `\` is needed. Otherwise, I align
> all the `\s` to the 80th column. Is this okay, or would you prefer that
> I align them all to the 80th column, or something else?
> 

This all sounds fine and I'm not nitpicking this style. Just the double
tabs making lines longer than required.