Hi Sam, On 12/5/22 00:09, Sam James wrote: > > >> On 4 Dec 2022, at 23:06, Sam James via Libc-alpha wrote: >> >> >> >>> On 4 Dec 2022, at 20:42, Alejandro Colomar via Libc-alpha wrote: >>> >>> Hi Helge, glibc developers, >>> >>> On 12/4/22 10:07, Helge Kreutzmann wrote: >>>> Without further ado, the following was found: >>>> Issue: Is the "L" in the bracket (for the NULL character) correct? >>>> "The B() function is the wide-character equivalent of the" >>>> "B(3) function. It copies at most I wide characters from the" >>>> "wide-character string pointed to by I, including the terminating null" >>>> "wide character (L\\(aq\\e0\\(aq), to the array pointed to by I." >>>> "Exactly I wide characters are written at I. If the length" >>>> "I is smaller than I, the remaining wide characters in the" >>>> "array pointed to by I are filled with null wide characters. If the" >>>> "length I is greater than or equal to I, the string pointed" >>>> "to by I will not be terminated by a null wide character." >>> >>> As an unrelated note. I've had this running in my mind for some time... your various bug reports for strncpy(3) and similar wide character functions have triggered those thougts. >>> >>> I'm going to mark strncpy(3) and similar functions as deprecated, even if no libc or standard has done so. There's wide agreement (at least in some communities) that strncpy(3) _is evil_. There's simply no use for it. >>> >> >> Please don't do this unilaterally. Apple did this unilaterally for sprintf which has caused problems, as well. > > snprintf, that is No, they deprecated sprintf(3), AFAIK. Cheers, Alex --