lib/libc/string: document restrict qualification of memccpy() arguments

[fuz]

Summary

POSIX.1-2004 and the upcoming C23 agree that memccpy()'s arguments
are restrict qualified and must not overlap. In 2002, restrict
qualifiers were added to <string.h>'s declaration of the function.
Make things official and document that the arguments must not
overlap.

See also D42902 for an amd64 SIMD implementation of memccpy().

See also: 61b60edfd3fff20f884419f8097870c7045315c9

Test Plan

passes build test

[kib]

lib/libc/string/bstring.3

61

Line is too long.
Use .Fo/.Ft to avoid it.

lib/libc/string/memccpy.3

95

What about saying which std version added the restict?

lib/libc/string/memccpy.c

39

We compile libc with C11 compiler. There is no need to use __restrict compat macro in libc source code (as opposed to public headers), use plain restrict.

[fuz]

Will fix the mentioned issues. Please state if you really want me to use restrict over __restrict and be inconsistent with the other functions. One time I'm doing something according to modern convention and be told to just be consistent with what the other code does, then I instead am consistent with the existing code and am told to disregard consistency. This is really frustrating. However I do it, it's somehow wrong.

lib/libc/string/memccpy.3

95

POSIX.1-2004 added the restrict keyword, which is why I cited it above. POSIX names the first standard to have memccpy to be SVID 1.

lib/libc/string/memccpy.c

39

I have followed the example of all the other string functions, which use __restrict. Are you sure I should introduce an inconsistence here?

[fuz]

• lib/libc/string/memccpy.3: stylistic fixes, amend history

It looks like 5.0.0 is the first FreeBSD version to have the restrict
qualifier in string.h, so adjust that.

[kib]

In D42905#979013, @fuz wrote:

Will fix the mentioned issues. Please state if you really want me to use restrict over __restrict and be inconsistent with the other functions. One time I'm doing something according to modern convention and be told to just be consistent with what the other code does, then I instead am consistent with the existing code and am told to disregard consistency. This is really frustrating. However I do it, it's somehow wrong.

I do not see a reason to use custom macros for code that is compiled by modern compilers. We recently eliminated PMAP_INLINE and __inline from pmap.c on all arches, as an example.

[kib]

So do whatever you want with restrict vs. __restrict. When the word 'frustrating' start appearing as a reaction to the review, I remember why I do not want to spend time on this.

[fuz]

• lib/libc/string/memccpy.c: __restrict -> restrict

As requested.

[fuz]

Committed in e0d4f419ac41aa91b862f3ceadc32a86abf08572.