On: Banned C standard library functions in Git source code

[ncmncm]

strlcpy is a terrible alternative. I have never seen it used correctly. It takes more and uglier code to use it correctly than to use strlen and strcpy. People who use it don't bother.

Finding use of strlcpy in a program is a red warning of sloppy code.

There are good reasons it was kept out of glibc for so long.

[jandrese → ncmncm]

I agree that strlcpy is braindamaged, but why in God's Green Earth isn't there a sensible replacement in stdlib in 2019? This shouldn't be that hard, yet the best alternative is I think snprintf, which is just so ugly. For a long time it wasn't used because compiler support was spotty, but it's been 20 years now so that shouldn't be a major issue anymore.

[baot → jandrese]

There is, it's strncpy_s and it was added in C11. And I know, nobody uses C11: that's a security failure.

[saagarjha → baot]

strncpy_s performs a lot of checks that might not be useful, though.

[ncmncm → jandrese]

The (more-or-less) sensible replacement is std::string. Adoption has been spotty, for practical, ideological, and fetishistic reasons.

The first step is to compile the C program with a C++ compiler. Next, start making improvements. If you skip the first step, the ceiling on improvements is limited.

[saagarjha → ncmncm]

C++≠C, and making the jump isn't always feasible.

[ncmncm → saagarjha]

As I said.

And when it's not, the ceiling on improvements is limited.