Hi Pail, On Wed, Nov 08, 2023 at 03:31:38PM -0800, Paul Eggert wrote: > On 11/8/23 14:11, Alejandro Colomar wrote: > > I just don't think we need, > > as GNU or Linux projects, to be restricted to the decisions of ISO. We > > can realize that certain functions are bad, and mark them as deprecated > > in our scope. > > There's enough use of strncpy for the intended use (smallish fixed size > character arrays that are null padded, not null terminated) that saying it's > deprecated would likely cause more trouble than it's worth. It's not just > utmp and tar; it's also socket programming (sun_path) and I'm sure other > stuff. > > Were we designing the C library from scratch I'd agree with you: in that > context, strncpy would clearly be more trouble than it's worth. But now that > we're stuck with strncpy we have better things to do than try to deprecate > it. No, no, I'm not trying to deprecate it. I was just saying that *iff* all of its uses were dead, I'd deprecate it. But they're clearly not dead, so it's a perfect function for those cases. > > Instead of saying "deprecate" I suggest we say something like "This function > is generally a poor choice for processing strings" and point to the longer > man page about strings in general. That's what the glibc manual does and it > works reasonably well. Yes, I've done something like this. string_copying(7) recommends avoiding fixed-width null-padded buffers in APIs. But for those use cases that already exist, this is the function to use. I'm also refusing to document how to (mis)use this function for truncating strings. If one wants to struncate strings, they'll need functions that were designed to do that (e.g., strlcpy(3)). Cheers, Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
