linux-kernel - Re: [PATCH] fixed coding style issues

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, 25 Jul 2012 15:44:02 +0800
From:	Baodong Chen <chenbdchenbd@...il.com>
To:	Joe Perches <joe@...ches.com>
Cc:	dmitry.torokhov@...il.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fixed coding style issues

i want to participate in and to start from
fixing simple issues!
how could i choose issues form checkpatch's output to find which
should be fixed which are
not?
or checkpatch.pl should be updated??

On Wed, Jul 25, 2012 at 3:30 PM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2012-07-25 at 15:11 +0800, Baodong Chen wrote:
>> Fexed coding style issues from scripts/checkpatch.pl in drivers/input
>
> Not all checkpatch messages need to be "fexed". :)
>
> Please use some taste and judgment before submitting
> patches based solely on checkpatch output.
>
>> diff --git a/drivers/input/apm-power.c b/drivers/input/apm-power.c
> []
>> @@ -33,7 +33,7 @@ static void system_power_event(unsigned int keycode)
>>  }
>>
>>  static void apmpower_event(struct input_handle *handle, unsigned int
>> type,
>> -                     unsigned int code, int value)
>> +                     unsigned int code, int value)
>
> Perhaps prefer alignment to immediately after open parenthesis.
>
>> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> []
>> @@ -547,16 +547,44 @@ static int handle_eviocgbit(struct input_dev *dev,
>>
>>       switch (type) {
>>
>> -     case      0: bits = dev->evbit;  len = EV_MAX;  break;
> []
>> +     case      0:
>> +             bits = dev->evbit;
>> +             len = EV_MAX;
>> +             break;
>
> not all that better really.
>
>> @@ -567,8 +595,8 @@ static int handle_eviocgbit(struct input_dev *dev,
>>       if (type == EV_KEY && size == OLD_KEY_MAX) {
>>               len = OLD_KEY_MAX;
>>               if (printk_timed_ratelimit(&keymax_warn_time, 10 * 1000))
>> -                     pr_warning("(EVIOCGBIT): Suspicious buffer size %u,
>> "
>> -                                "limiting output to %zu bytes. See "
>> +                     pr_warn("(EVIOCGBIT): Suspicious buffer size %u, "
>> \
>> +                                "limiting output to %zu bytes. See " \
>
> The line continuations are also not necessary and I think are
> really ugly.  Just coalesce the format.
>
>>
>> "http://userweb.kernel.org/~dtor/eviocgbit-bug.html\n",
>
> dead link I think.
>
>> diff --git a/drivers/input/ff-core.c b/drivers/input/ff-core.c
> []
>> @@ -138,8 +138,8 @@ int input_ff_upload(struct input_dev *dev, struct
>> ff_effect *effect,
>>
>>       if (effect->id == -1) {
>>               for (id = 0; id < ff->max_effects; id++)
>> -                  if (!ff->effect_owners[id])
>> -                     break;
>> +                     if (!ff->effect_owners[id])
>> +                             break;
>
> Better surrounded by braces too.
>
> cheers, Joe
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/