Git's list of banned C functions

Re:Git's list of banned C functions by kzrdude on Thursday March 04, 2021 @04:46PM (#26348853)

You have found the answer - strlcpy is not a replacement for strncpy at all (it's arguably a safer version of strcpy), and git people didn't invent this, it's the existing BSD strlcpy interface.

[ Parent | on HN ]

Re:Git's list of banned C functions by attractivechaos on Thursday March 04, 2021 @04:51PM (#26348929)

Thanks for the confirmation. But my concern remains: they banned strncpy without a proper replacement. In addition, I didn't know the extra restriction of strlcpy until today (I have never used it before because it is not conforming to C99/POSIX). I might have fallen into this trap.

[ Parent | on HN ]

Re:Git's list of banned C functions by notaplumber on Thursday March 04, 2021 @05:26PM (#26349340)

The problem is the actually often the opposite, in the real world many treat strncpy as if it behaves like strlcpy. Note that strlcpy is equivalent to:

    snprintf(buf, sizeof(buf), "%s", string);

strlcpy is on track for future standardization in POSIX, for Issue 8, but even as a de facto standard, it exists in libc on *BSD, macOS, Android, Solaris, QNX, and even Linux using musl.

https://www.austingroupbugs.net/view.php?id=986#c5050

But you're correct in that it is not a replacement for strncpy because no code should be using strncpy.

[ Parent | on HN ]