Hi Paul, On Wed, Nov 08, 2023 at 03:06:40PM -0800, Paul Eggert wrote: > On 11/8/23 14:17, Alejandro Colomar wrote: > > These copy*from* a string > > Not necessarily. For example, in strncpy (DST, SRC, N), SRC need not be a > string. Pedantically, true. But since it's quite rare to copy from a fixed-width null-padded array into another, I didn't want to waste space on that and possibly confuse readers. In such a case, the source buffer must be at least as large as the destination buffer, and will likely be the same size (because having fixed-width stuff, why make it different), so memcpy(3) will probably be simpler. > > By the way, have you looked at the recent (i.e., this-year) changes to the > glibc manual's string section? They're relevant. I hadn't; after your message, I have. <https://sourceware.org/glibc/manual/2.38/html_mono/libc.html#String-and-Array-Utilities> I like how it connects all the functions, and it explains the concepts and gives advice (e.g., avoid truncation as it's usually evil), and compares the different functions. However, I think it misses a few things: - strncpy(3) and strncat(3) are not related at all. They don't have the same relation that strcpy(3) and strcat(3) have. You can't write the following code in any case: strncpy(dst, foo, sizeof(dst)); strncat(dst, bar, sizeof(dst)); as you would with strcpy(3) or strlcpy(3). strncpy(3) and strncat(3) are opposite functions: the former reads from a string and writes to a fixed-width null-padded buffer, and the latter reads from a fixed-width buffer and writes to a string. (You can use them in other cases, pedantically, as you said above, but those cases are rather unreal.) - strncpy(3) is in a section that starts by saying: > The functions described in this section copy or concatenate the > possibly-truncated contents of a string or array to another This may mislead programmers to believe it is useful for producing strings, when it's not. In general, I would like the manual to put some more distance between these functions and the term "string". As DJ mentioned, it might be useful to mention utmp(5) and tar(1) as niche use cases for st[rp]ncpy(3). And now for some typo: - In the following sentence under "5.2 String and Array Conventions": > The array arguments and return values for these functions have type > void * or wchar_t. I believe it meant `void *` or `wchar_t *` Cheers, Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature