Fix #2777, compiler false positive in xcursor.c

[yuja]

This reverts commit 7dffe93, which introduced
another linter error with -O3:

  error: ‘strncat’ specified bound 7 equals source length [-Werror=stringop-overflow=]

and replace strncpy() with memcpy() to suppress the original warning.

[kennylevinsen]

@yuja can you reproduce the original warning to verify that this fixes it? I don't recall experiencing it myself, in which case I'm unable to verify it as fixed.

[yuja]

Sorry, I can't reproduce the original truncation warning even with s390x-linux-gnu-gcc-10. Maybe need an s390x VM?
I needed to comment out the path[pathlen + len] = '\0' line to get that, which clearly makes the warning correct.

The use of memcpy() is documented way to suppress the false positive, so I think it would
avoid the problem reported in #2018.

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-truncation

[emersion]

The use of memcpy() is documented way to suppress the false positive

The manual says:

To avoid the warning when the result is not expected to be NUL-terminated, call memcpy instead.

However we expect the result to be NUL-terminated here.

[yuja]

we expect the result to be NUL-terminated here.

No, we don't always expect that. Since elt may be a part of comma-separated string (e.g. /usr/local:/usr),
we do append NUL at the end. strncat() would do that automatically, but it introduced another false positive.

[emersion]

The result is the output of the function, not the input. elt is an input.

[yuja]

Yes. I mean elt is partial string, so we can't always make strncpy() copy the NUL byte from elt.
So the result of strncpy() is not expected to be NUL terminated.
That's why we do append NUL.

[emersion]

Hm, I see. So the memcpy can never copy past the end of elt.

Thanks for the explanation. This file is terrible.