diff mbox series

[v2,03/11] selftests/mm: fix "warning: expression which evaluates to zero..." in mlock2-tests.c

Message ID 20230603021558.95299-4-jhubbard@nvidia.com (mailing list archive)
State Accepted
Commit b764253c18821da31c49a260f92f5d093cf1637e
Headers show
Series A minor flurry of selftest/mm fixes | expand

Commit Message

John Hubbard June 3, 2023, 2:15 a.m. UTC
The stop variable is a char*, and the code was assigning a char value to
it. This was generating a warning when compiling with clang.

However, as both David and Peter pointed out, stop is not even used
after the problematic assignment to a char type. So just delete that
line entirely.

Cc: David Hildenbrand <david@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 tools/testing/selftests/mm/mlock2-tests.c | 1 -
 1 file changed, 1 deletion(-)

Comments

David Hildenbrand June 5, 2023, 11:36 a.m. UTC | #1
On 03.06.23 04:15, John Hubbard wrote:
> The stop variable is a char*, and the code was assigning a char value to
> it. This was generating a warning when compiling with clang.
> 
> However, as both David and Peter pointed out, stop is not even used
> after the problematic assignment to a char type. So just delete that
> line entirely.
> 
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---

Reviewed-by: David Hildenbrand <david@redhat.com>
Peter Xu June 5, 2023, 3:43 p.m. UTC | #2
On Fri, Jun 02, 2023 at 07:15:50PM -0700, John Hubbard wrote:
> The stop variable is a char*, and the code was assigning a char value to
> it. This was generating a warning when compiling with clang.
> 
> However, as both David and Peter pointed out, stop is not even used
> after the problematic assignment to a char type. So just delete that
> line entirely.
> 
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
>  tools/testing/selftests/mm/mlock2-tests.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/mm/mlock2-tests.c b/tools/testing/selftests/mm/mlock2-tests.c
> index 11b2301f3aa3..80cddc0de206 100644
> --- a/tools/testing/selftests/mm/mlock2-tests.c
> +++ b/tools/testing/selftests/mm/mlock2-tests.c
> @@ -50,7 +50,6 @@ static int get_vm_area(unsigned long addr, struct vm_boundaries *area)
>  			printf("cannot parse /proc/self/maps\n");
>  			goto out;
>  		}
> -		stop = '\0';
>  
>  		sscanf(line, "%lx", &start);
>  		sscanf(end_addr, "%lx", &end);

I'd rather simply make it "*stop = '\0'", or as David suggested dropping
stop completely when we're it (assumes that scanf() will always work with
number ending with space ' ').

No strong opinion here, though.
John Hubbard June 5, 2023, 7:23 p.m. UTC | #3
On 6/5/23 08:43, Peter Xu wrote:
> On Fri, Jun 02, 2023 at 07:15:50PM -0700, John Hubbard wrote:
>> The stop variable is a char*, and the code was assigning a char value to
>> it. This was generating a warning when compiling with clang.
>>
>> However, as both David and Peter pointed out, stop is not even used
>> after the problematic assignment to a char type. So just delete that
>> line entirely.
>>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: Peter Xu <peterx@redhat.com>
>> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
>> ---
>>   tools/testing/selftests/mm/mlock2-tests.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/mm/mlock2-tests.c b/tools/testing/selftests/mm/mlock2-tests.c
>> index 11b2301f3aa3..80cddc0de206 100644
>> --- a/tools/testing/selftests/mm/mlock2-tests.c
>> +++ b/tools/testing/selftests/mm/mlock2-tests.c
>> @@ -50,7 +50,6 @@ static int get_vm_area(unsigned long addr, struct vm_boundaries *area)
>>   			printf("cannot parse /proc/self/maps\n");
>>   			goto out;
>>   		}
>> -		stop = '\0';
>>   
>>   		sscanf(line, "%lx", &start);
>>   		sscanf(end_addr, "%lx", &end);
> 
> I'd rather simply make it "*stop = '\0'", or as David suggested dropping
> stop completely when we're it (assumes that scanf() will always work with
> number ending with space ' ').

Actually it does not assume that. Rather, it follows the documented behavior
of strchr(3), which is:

     The strchr() and strrchr() functions return a pointer to the matched
     character or NULL if the character is not found. The terminating
     null byte is considered part of the string, so that if c is
     specified as '\0', these functions return a pointer to the
     terminator.

And we have this code now:

	stop = strchr(end_addr, ' ');
	if (!stop) {
		printf("cannot parse /proc/self/maps\n");
		goto out;
	}

So, either stop has a valid char* in it, or we goto out. There are no
fragile assumptions in there, as far as I can see anyway.

> 
> No strong opinion here, though.
> 

OK, I think it's kind of a flip of the coin whether to write this:

	stop = strchr(end_addr, ' ');
	if (!stop) {

or this:

	if (!strchr(end_addr, ' ')) {

So I'll just leave it as the first one, which (depending on the
day of the week) might read slightly clearer. :)


thanks,
diff mbox series

Patch

diff --git a/tools/testing/selftests/mm/mlock2-tests.c b/tools/testing/selftests/mm/mlock2-tests.c
index 11b2301f3aa3..80cddc0de206 100644
--- a/tools/testing/selftests/mm/mlock2-tests.c
+++ b/tools/testing/selftests/mm/mlock2-tests.c
@@ -50,7 +50,6 @@  static int get_vm_area(unsigned long addr, struct vm_boundaries *area)
 			printf("cannot parse /proc/self/maps\n");
 			goto out;
 		}
-		stop = '\0';
 
 		sscanf(line, "%lx", &start);
 		sscanf(end_addr, "%lx", &end);