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

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:   Mon, 5 Jun 2023 12:23:36 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Peter Xu <peterx@...hat.com>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>,
        Shuah Khan <shuah@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>, <linux-mm@...ck.org>,
        <linux-kselftest@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 03/11] selftests/mm: fix "warning: expression which
 evaluates to zero..." in mlock2-tests.c

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@...hat.com>
>> Cc: Peter Xu <peterx@...hat.com>
>> Signed-off-by: John Hubbard <jhubbard@...dia.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,
-- 
John Hubbard
NVIDIA