Hi Zack! On Wed, Nov 08, 2023 at 09:06:48AM -0500, Zack Weinberg wrote: > >> If you ask me, I'd not mark libc functions as deprecated without some > >> kind of consesnsus from the libc maintainers too. > ... > > Okay, let's ask them. > ... > > Hi glibc developers, > > > > strncpy(3) > ... > > Speaking only for myself, I would be very reluctant to declare any > standardized function "deprecated" by glibc unless the relevant > standards have also made that declaration. This goes double for > anything that was in C89. I understand your point of view, but disagree with it. Deprecation by ISO C or POSIX takes very very long. We had gets(3) for decades until they realized it should be removed from the standards. STANDARDS POSIX.1‐2008. HISTORY C89, POSIX.1‐2001. LSB deprecates gets(). POSIX.1‐2008 marks gets() obsoles‐ cent. ISO C11 removes the specification of gets() from the C language, and since glibc 2.16, glibc header files don’t expose the function declaration if the _ISOC11_SOURCE fea‐ ture test macro is defined. So we had it in ISO C in C89 and C99, and only in C11 they realized it had to be removed. POSIX hasn't even removed it yet! I won't hesitate to kill a function just because of bureaucracy. The standard, especially C89, was just a reflection of the commonalities of most implementation. It was a burden of implementations to add new stuff or to remove existing stuff. Later revisions of the standards invented more, though. In this case, since ISO C has no APIs that use strncpy(3), it could (and should) already deprecate strncpy(3) from ISO C. POSIX still needs it while it keeps utmpx(5), because there's no other way to correctly write to the fixed-width buffers within struct utmpx. > > Also speaking only for myself, the Linux manpages are welcome to > discourage the use of any function that you feel is not a wise choicei > for new programs, but the word "deprecated" should be reserved for > cases where there really has been a declaration of deprecation by us > and/or the standards. If a function is deprecated by a standard or other entity, that will be reflected in the STANDARDS or HISTORY section. For deprecation by the manual itself, the SYNOPSIS (and BUGS) sections are fine. In the end, the word 'deprecate' isn't any magic. From WordNet (r) 3.0 (2006) [wn]: deprecate v 1: express strong disapproval of; deplore That term applies to strncpy(3). > The word "obsolete" should also be used very cautiously; it's broader, > but I personally would only use it in situations where there is a > direct replacement (e.g. sigaction replaces signal, strsep replaces strtok and strtok_r). > > In the specific cases we're discussing: I would definitely like to see > a BUGS or NOTES section in the strncpy(3) manpage, warning people that > it's probably not what they want and recommending use of strlen+memcpy > instead. I don't know enough about the utmp(x) situation to have a > strong opinion, but I do think the manpages need to be very clear that > this particular proposed replacement for utmp(x) is Linux-specific and > still somewhat experimental. But yes, we need to make sure that the APIs that need strncpy(3) are all deprecated. If other Unix systems still need utmpx or similar stuff, strncpy(3) will still be necessary. Cheers, Alex > > zw -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
