On Wed, Nov 08, 2023 at 12:18:09AM -0600, Oskari Pirhonen wrote: > On Tue, Nov 07, 2023 at 17:17:29 +0100, Alejandro Colomar wrote: > > > > I would love to find this API useless, and in that case, I'd go further > > and add [[deprecated]] in the synopsis, and write a heavy statement in a > > BUGS section. But I can't do that while it's still a good function in > > some cases (even if those cases are bad design, such as utmp(5)). > > > > On the other hand, utmp(5) has other issues, like Y2038, and AFAIR it's > > being deprecated, so maybe we could consider deprecating strncpy(3). > > > > If I see enough proof that all APIs that require this function are > > deprecated, I'll happily declare the function deprecated as well. > > (in fact I already did some time ago, but then found this use with > > utmp(5), which is why I removed the deprecation; see > > <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man3/strncpy.3?id=30d458d1a6261221bad15e58f1862e0dda24f4a0>). > > > > If you ask me, I'd not mark libc functions as deprecated without some > kind of consesnsus from the libc maintainers too. They may not go so far > as to add the `deprecated` attribute in their own headers, at least not > yet at that point in time, but some kind of written "Yes, please don't > use this function" would be nice to have before marking them in the man > pages. Okay, let's ask them. Hi glibc developers, strncpy(3) is useful to write to fixed-width buffers like `struct utmp` and `struct utmpx`. Is there any other libc API that needs strncpy(3)? Of those two APIs (utmp and utmpx) and any other that need strncpy(3), are those deprecated, or is any such API still good for new code? If all APIs that need strncpy(3) are deprecated, I propose recommending against its use in new code. Thanks, Alex > > - Oskari -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
