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@xxxxxxxxxx>
Cc: Peter Xu <peterx@xxxxxxxxxx>
Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>
---
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
