From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752616AbdK0W5B (ORCPT ); Mon, 27 Nov 2017 17:57:01 -0500 Received: from ale.deltatee.com ([207.54.116.67]:58828 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbdK0W47 (ORCPT ); Mon, 27 Nov 2017 17:56:59 -0500 To: Julia Lawall Cc: Joe Perches , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Andy Whitcroft References: <20171126054037.9743-1-logang@deltatee.com> <1511676085.20482.18.camel@perches.com> <5c0a2778-8e8f-9fbb-b13f-1d880acb949b@deltatee.com> <1511735382.20482.27.camel@perches.com> <355029d1-48f5-095e-0d99-bb726d2d56e5@deltatee.com> <86f3f594-79f7-c2ce-2cc6-f641bd6f55ae@deltatee.com> <1511771322.32426.1.camel@perches.com> <1511803686.32426.54.camel@perches.com> <322acd87-7708-cc90-c3d1-caad7bd023e5@deltatee.com> <1511804568.32426.56.camel@perches.com> <1511809027.32426.62.camel@perches.com> <993ca1c1-6d27-2ee1-94ed-41e8249755bd@deltatee.com> From: Logan Gunthorpe Message-ID: <3ddea7e4-24bd-eadc-18ff-ab5aa5d81e58@deltatee.com> Date: Mon, 27 Nov 2017 15:56:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: apw@canonical.com, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, joe@perches.com, julia.lawall@lip6.fr X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/11/17 01:49 PM, Julia Lawall wrote: > Perhaps if there is a possible flow from one print to another within a > single function and in both cases the format string is at least say 25 > characters (completely random value), then it is pretty likely that a > newline is intended. This is on the edge of what I think could be done with checkpatch. I did a quick look through some of the cases I've noticed and haven't found any that this wouldn't pass. I'm not sure how you'd pick an appropriate threshold though. I do think it's quite clever, though. > Alternatively, if the first format string doesn't end in a space and the > second one doesn't begin with a space, then a newline is also likely > intended. This makes more sense to me but I don't expect it to be 100% accurate either. See, for example, drivers/char/dtlk.c:640 which has no space in either printk. You could maybe expand the rule to include ':' and '(' as the last character. Logan