lkml.org 
[lkml]   [2016]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3 0/4] Introduce the latent_entropy gcc plugin
On Wed, Jun 15, 2016 at 1:39 PM, Emese Revfy <re.emese@gmail.com> wrote:
> On Wed, 15 Jun 2016 11:55:44 -0700
> Kees Cook <keescook@chromium.org> wrote:
>
>> The limit on the length of lines is 80 columns and this is a strongly
>> preferred limit.
>
> I think the code looks worse when it is truncated to 80 columns but
> I'll do it and resend the patches.

Yup, I understand your concerns, but since we're optimizing for
readability by a larger audience that has agreed to the guidelines in
CodingStyle, this is what we get. :)

One area I'm unclear on with kernel coding style, though, is if
splitting all the stuff prior to function name onto a separate line is
"acceptable", since that solves most of the long lines where
__latent_entropy has been added. For example, I don't know which is
better:

All on one line (gmail may split this, but my intention is all one line):

static __latent_entropy void rcu_process_callbacks(struct
softirq_action *unused)

Types and attributes on a separate line:

static __latent_entropy void
rcu_process_callbacks(struct softirq_action *unused)

All arguments on the next line:

static __latent_entropy void rcu_process_callbacks(
struct
softirq_action *unused)


Greg, do you have a better sense of how to split (or not split) these
kinds of long lines?

-Kees

--
Kees Cook
Chrome OS & Brillo Security

\
 
 \ /
  Last update: 2016-06-16 01:21    [W:0.053 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site