RE: https://hachyderm.io/@kees/116282745861595200

Fun to see the Linux kernel follow in #curl's footsteps! 😎 (we removed the last strncpy from curl in late 2025)

Do I understand correctly that the problem with strncpy is that after the call you don’t know if the buffer is NUL terminated or not?
@kasperd yes. but we also find that code generally improves using other solutions so in curl we don't replace it with something that guarantees a null terminator. We write the code another way instead.

@bagder
@kasperd

Is that implementation-defined? I've had no issues on linux but noticed that earlier MinGW gcc on windows wouldn't terminate on limit.

If the input string is longer than the given limit the output buffer will have no NUL character. As far as I can tell that’s the behavior required by the specification.

If you are lucky there might be a NUL character just after the buffer. But that’s not something you can count on.

What also came as a surprise to me is that it pads the buffer with NUL bytes if the string is shorter. That may be desirable for some use cases, but I think in more common scenarios that just hurts performance.

@kasperd
Ah, yes, I was confusing with strnprintf.
@bagder