[PATCH] checkpatch: Flag code that returns a negative number

[PATCH] checkpatch: Flag code that returns a negative number

[Nishanth Menon]

In some functions, returning a -ve decimal value is actually a valid
return condition when the function is returning a value, however, it
can also be misused for returning an error value that should ideally
be a valid error code defined in include/uapi/asm-generic/errno-base.h
or include/uapi/asm-generic/errno.h

Considering typical newbie error of doing the following:
int fn(void)
{
	/* ... error condition ... */
	return -1;
}

void fn1(void)
{
	/* some code */
	if (fn() < 0) {
		pr_err("Error occurred\n");
		return;
	}
	/* other cases... */
}

Flag this as a check case for developer verification.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 scripts/checkpatch.pl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4904ced676d4..f6fa07fe33a5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4351,6 +4351,12 @@ sub process {
 			}
 		}
 
+# return with a value is not usually a good sign, unless the function is supposed to return a value
+		if (defined($stat) && $stat =~ /^.\s*return\s*-[0-9]+\s*;/s) {
+			CHK("RETURN_NUMBER",
+			    "Suspect error return with a value, If this is error value, refer to include/uapi/asm-generic/errno-base.h  and include/uapi/asm-generic/errno.h\n" . $herecurr);
+		}
+
 # unnecessary return in a void function
 # at end-of-function, with the previous line a single leading tab, then return;
 # and the line before that not a goto label target like "out:"
-- 
2.8.0

Re: [PATCH] checkpatch: Flag code that returns a negative number

[Joe Perches]

On Fri, 2016-06-03 at 10:25 -0500, Nishanth Menon wrote:
> In some functions, returning a -ve decimal value is actually a valid
> return condition when the function is returning a value, however, it
> can also be misused for returning an error value that should ideally
> be a valid error code defined in include/uapi/asm-generic/errno-base.h
> or include/uapi/asm-generic/errno.h
> 
> Considering typical newbie error of doing the following:
> int fn(void)
> {
> 	/* ... error condition ... */
> 	return -1;
> }
> 
> void fn1(void)
> {
> 	/* some code */
> 	if (fn() < 0) {
> 		pr_err("Error occurred\n");
> 		return;
> 	}
> 	/* other cases... */
> }
> 
> Flag this as a check case for developer verification.

I think it's not a newbie error to have a -1 return and it
seems like rather too many cases to even suggest be changed.

$ git grep -E "\breturn\s+\-\s*[0-9]+" * | grep -v "^tools" | wc -l
8388


> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4351,6 +4351,12 @@ sub process {
>  			}
>  		}
>  
> +# return with a value is not usually a good sign, unless the function is supposed to return a value
> +		if (defined($stat) && $stat =~ /^.\s*return\s*-[0-9]+\s*;/s) {
> +			CHK("RETURN_NUMBER",
> +			    "Suspect error return with a value, If this is error value, refer to include/uapi/asm-generic/errno-base.h  and include/uapi/asm-generic/errno.h\n" . $herecurr);
> +		}
> +
>  # unnecessary return in a void function
>  # at end-of-function, with the previous line a single leading tab, then return;
>  # and the line before that not a goto label target like "out:"

Re: [PATCH] checkpatch: Flag code that returns a negative number

[Andrew F. Davis]

On 06/03/2016 10:41 AM, Joe Perches wrote:
> On Fri, 2016-06-03 at 10:25 -0500, Nishanth Menon wrote:
>> In some functions, returning a -ve decimal value is actually a valid
>> return condition when the function is returning a value, however, it
>> can also be misused for returning an error value that should ideally
>> be a valid error code defined in include/uapi/asm-generic/errno-base.h
>> or include/uapi/asm-generic/errno.h
>>
>> Considering typical newbie error of doing the following:
>> int fn(void)
>> {
>> 	/* ... error condition ... */
>> 	return -1;
>> }
>>
>> void fn1(void)
>> {
>> 	/* some code */
>> 	if (fn() < 0) {
>> 		pr_err("Error occurred\n");
>> 		return;
>> 	}
>> 	/* other cases... */
>> }
>>
>> Flag this as a check case for developer verification.
> 
> I think it's not a newbie error to have a -1 return and it
> seems like rather too many cases to even suggest be changed.
> 
> $ git grep -E "\breturn\s+\-\s*[0-9]+" * | grep -v "^tools" | wc -l
> 8388
> 

A quick look over some of these cases show many *should* be replaced
with proper error codes.

Removing the simple -1 case, which is often used for signaling one level
up of an error, gives better results though:

$ git grep -E "\breturn\s+\-\s*[2-9][0-9]*" * | grep -v "^tools" | wc -l
189

Andrew

> 
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
>> @@ -4351,6 +4351,12 @@ sub process {
>>  			}
>>  		}
>>  
>> +# return with a value is not usually a good sign, unless the function is supposed to return a value
>> +		if (defined($stat) && $stat =~ /^.\s*return\s*-[0-9]+\s*;/s) {
>> +			CHK("RETURN_NUMBER",
>> +			    "Suspect error return with a value, If this is error value, refer to include/uapi/asm-generic/errno-base.h  and include/uapi/asm-generic/errno.h\n" . $herecurr);
>> +		}
>> +
>>  # unnecessary return in a void function
>>  # at end-of-function, with the previous line a single leading tab, then return;
>>  # and the line before that not a goto label target like "out:"

Re: [PATCH] checkpatch: Flag code that returns a negative number

[Joe Perches]

On Fri, 2016-06-03 at 10:49 -0500, Andrew F. Davis wrote:
> On 06/03/2016 10:41 AM, Joe Perches wrote:
> > On Fri, 2016-06-03 at 10:25 -0500, Nishanth Menon wrote:
> > > In some functions, returning a -ve decimal value is actually a valid
> > > return condition when the function is returning a value, however, it
> > > can also be misused for returning an error value that should ideally
> > > be a valid error code defined in include/uapi/asm-generic/errno-base.h
> > > or include/uapi/asm-generic/errno.h
> > > 
> > > Considering typical newbie error of doing the following:
> > > int fn(void)
> > > {
> > > 	/* ... error condition ... */
> > > 	return -1;
> > > }
> > > 
> > > void fn1(void)
> > > {
> > > 	/* some code */
> > > 	if (fn() < 0) {
> > > 		pr_err("Error occurred\n");
> > > 		return;
> > > 	}
> > > 	/* other cases... */
> > > }
> > > 
> > > Flag this as a check case for developer verification.
> > I think it's not a newbie error to have a -1 return and it
> > seems like rather too many cases to even suggest be changed.
> > 
> > $ git grep -E "\breturn\s+\-\s*[0-9]+" * | grep -v "^tools" | wc -l
> > 8388
> > 
> A quick look over some of these cases show many *should* be replaced
> with proper error codes.
> 
> Removing the simple -1 case, which is often used for signaling one level
> up of an error, gives better results though:
> 
> $ git grep -E "\breturn\s+\-\s*[2-9][0-9]*" * | grep -v "^tools" | wc -l
> 189

I did more or less the same grep, and that's somewhat true.
-1 though is very common and doesn't need to be replaced.

$ git grep -E "\breturn\s+\-\s*[0-9]+\s*;" * | grep -v "^tools" | grep -vP "return\s*\-1;" | wc -l
211

Looking at some of the specific instances of negative return values
instead of the line counts though may show otherwise.

-EFOO errors aren't always better.

Re: [PATCH] checkpatch: Flag code that returns a negative number

[Nishanth Menon]

On 06/03/2016 11:01 AM, Joe Perches wrote:

[...]
> I did more or less the same grep, and that's somewhat true.
> -1 though is very common and doesn't need to be replaced.
OK,

> 
> $ git grep -E "\breturn\s+\-\s*[0-9]+\s*;" * | grep -v "^tools" | grep -vP "return\s*\-1;" | wc -l
> 211
> 
> Looking at some of the specific instances of negative return values
> instead of the line counts though may show otherwise.
> 
> -EFOO errors aren't always better.
At least would'nt be a little more readable than obscure -val?

Would we like -[2-9][0-9]* flagged at all even as a check?

-- 
Regards,
Nishanth Menon

Re: [PATCH] checkpatch: Flag code that returns a negative number

[Joe Perches]

On Fri, 2016-06-03 at 11:07 -0500, Nishanth Menon wrote:
> On 06/03/2016 11:01 AM, Joe Perches wrote:
> 
> [...]
> > 
> > I did more or less the same grep, and that's somewhat true.
> > -1 though is very common and doesn't need to be replaced.
> OK,
> 
> > 
> > 
> > $ git grep -E "\breturn\s+\-\s*[0-9]+\s*;" * | grep -v "^tools" |
> > grep -vP "return\s*\-1;" | wc -l
> > 211
> > 
> > Looking at some of the specific instances of negative return values
> > instead of the line counts though may show otherwise.
> > 
> > -EFOO errors aren't always better.
> At least would'nt be a little more readable than obscure -val?
> 
> Would we like -[2-9][0-9]* flagged at all even as a check?

I think not, but you should look at the other !-1 instances
and see what you think.

But if it does, it should probably use '-\s*{?!1\b)\d+'

and it should certainly exclude files in tools.

[PATCH V2] checkpatch: Flag code that returns a negative number less than 1

[Nishanth Menon]

In some functions, returning a -ve decimal value is actually a valid
return condition when the function is returning a value, however, it
can also be misused for returning an error value that should ideally
be a valid error code defined in include/uapi/asm-generic/errno-base.h
or include/uapi/asm-generic/errno.h. The notable exception is "-1"
which has quiet a history of usage as pointed out by Joe Perches.

Considering typical error of doing the following:
int fn(void)
{
	/* ... error condition ... */
	return -2;
}

void fn1(void)
{
	/* some code */
	if (fn() < 0) {
		pr_err("Error occurred\n");
		return;
	}
	/* other cases... */
}

Flag this as a check case for developer verification.

The check is done for negative values less than 1 and tools
directory is exempt from this requirement based on Joe Perches'
suggestion.

Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in V2:
	- change in regex for check for check for less than 1
	- Update in commit message to the effect
	- Added Suggested-by for Joe's recommendation on regex.

V1: https://patchwork.kernel.org/patch/9153345/

 scripts/checkpatch.pl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4904ced676d4..a2e677b5fd78 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4351,6 +4351,12 @@ sub process {
 			}
 		}
 
+# return with a value is not usually a good sign, unless the function is supposed to return a value
+		if ($realfile !~ /^tools/ && defined($stat) && $stat =~ /^.\s*return\s*-\s*(?!1\b)\d+\s*;/s) {
+			CHK("RETURN_NUMBER",
+			    "Suspect error return with a value, If this is error value, refer to include/uapi/asm-generic/errno-base.h  and include/uapi/asm-generic/errno.h\n" . $herecurr);
+		}
+
 # unnecessary return in a void function
 # at end-of-function, with the previous line a single leading tab, then return;
 # and the line before that not a goto label target like "out:"
-- 
2.8.0

Re: [PATCH V2] checkpatch: Flag code that returns a negative number less than 1

[Joe Perches]

On Fri, 2016-06-03 at 15:02 -0500, Nishanth Menon wrote:
> In some functions, returning a -ve decimal value is actually a valid
> return condition when the function is returning a value, however, it
> can also be misused for returning an error value that should ideally
> be a valid error code defined in include/uapi/asm-generic/errno-base.h
> or include/uapi/asm-generic/errno.h. The notable exception is "-1"
> which has quiet a history of usage as pointed out by Joe Perches.
> 
> Considering typical error of doing the following:
> int fn(void)
> {
> 	/* ... error condition ... */
> 	return -2;
> }
> 
> void fn1(void)
> {
> 	/* some code */
> 	if (fn() < 0) {
> 		pr_err("Error occurred\n");
> 		return;
> 	}
> 	/* other cases... */
> }
> 
> Flag this as a check case for developer verification.
> 
> The check is done for negative values less than 1 and tools
> directory is exempt from this requirement based on Joe Perches'
> suggestion.
> 
> Suggested-by: Joe Perches <joe@perches.com>

No, I didn't suggest this.
I'm not at all sure it's even a good idea.

> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Changes in V2:
> 	- change in regex for check for check for less than 1
> 	- Update in commit message to the effect
> 	- Added Suggested-by for Joe's recommendation on regex.
> 
> V1: https://patchwork.kernel.org/patch/9153345/
> 
>  scripts/checkpatch.pl | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4904ced676d4..a2e677b5fd78 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4351,6 +4351,12 @@ sub process {
>  			}
>  		}
>  
> +# return with a value is not usually a good sign, unless the function is supposed to return a value
> +		if ($realfile !~ /^tools/ && defined($stat) && $stat =~ /^.\s*return\s*-\s*(?!1\b)\d+\s*;/s) {

I think
	if ($realfile != /^tools/ && $line =~ /\breturn\s*-\s*(?!1\b)\d+\s*;/
would be better as it would catch return -2 in a macro or a
multi-line statement like
	if (<foo>) return -2;

> +			CHK("RETURN_NUMBER",
> +			    "Suspect error return with a value, If this is error value, refer to include/uapi/asm-generic/errno-base.h  and include/uapi/asm-generic/errno.h\n" . $herecurr);

That's an awfully long message.

Maybe something like:
	"Perhaps better to use standard ERRNO system error symbols"

Re: [PATCH V2] checkpatch: Flag code that returns a negative number less than 1

[Nishanth Menon]

On 06/03/2016 03:42 PM, Joe Perches wrote:
> On Fri, 2016-06-03 at 15:02 -0500, Nishanth Menon wrote:
>> In some functions, returning a -ve decimal value is actually a valid
>> return condition when the function is returning a value, however, it
>> can also be misused for returning an error value that should ideally
>> be a valid error code defined in include/uapi/asm-generic/errno-base.h
>> or include/uapi/asm-generic/errno.h. The notable exception is "-1"
>> which has quiet a history of usage as pointed out by Joe Perches.
>>
>> Considering typical error of doing the following:
>> int fn(void)
>> {
>> 	/* ... error condition ... */
>> 	return -2;
>> }
>>
>> void fn1(void)
>> {
>> 	/* some code */
>> 	if (fn() < 0) {
>> 		pr_err("Error occurred\n");
>> 		return;
>> 	}
>> 	/* other cases... */
>> }
>>
>> Flag this as a check case for developer verification.
>>
>> The check is done for negative values less than 1 and tools
>> directory is exempt from this requirement based on Joe Perches'
>> suggestion.
>>
>> Suggested-by: Joe Perches <joe@perches.com>
> 
> No, I didn't suggest this.

Sorry, I had hoped to give you credit for the recommended regex
optimization and recommendations you gave.

> I'm not at all sure it's even a good idea.

OK. I can drop this if we'd not want to go down this road. we can
catch stuff in review as much as possible, I was hoping we can catch
the easy ones by forcing a relook by developers.

> 
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> Changes in V2:
>> 	- change in regex for check for check for less than 1
>> 	- Update in commit message to the effect
>> 	- Added Suggested-by for Joe's recommendation on regex.
>>
>> V1: https://patchwork.kernel.org/patch/9153345/
>>
>>  scripts/checkpatch.pl | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index 4904ced676d4..a2e677b5fd78 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -4351,6 +4351,12 @@ sub process {
>>  			}
>>  		}
>>  
>> +# return with a value is not usually a good sign, unless the function is supposed to return a value
>> +		if ($realfile !~ /^tools/ && defined($stat) && $stat =~ /^.\s*return\s*-\s*(?!1\b)\d+\s*;/s) {
> 
> I think
> 	if ($realfile != /^tools/ && $line =~ /\breturn\s*-\s*(?!1\b)\d+\s*;/
> would be better as it would catch return -2 in a macro or a
> multi-line statement like
> 	if (<foo>) return -2;
> 
Nice.

>> +			CHK("RETURN_NUMBER",
>> +			    "Suspect error return with a value, If this is error value, refer to include/uapi/asm-generic/errno-base.h  and include/uapi/asm-generic/errno.h\n" . $herecurr);
> 
> That's an awfully long message.
> 
> Maybe something like:
> 	"Perhaps better to use standard ERRNO system error symbols"
> 

Fair enough. Will hold off a respin based on direction we would like
to take.


-- 
Regards,
Nishanth Menon