At some point in the past, a huge effort was expended to incorporate support for strlcpy and strlcat into all of the FUSS codebases (and AFKMud). Since these functions, at the time, were only available on OpenBSD systems, everyone else essentially had to hand roll their own versions. Which we did in the form of mudstrlcpy and mudstrlcat.

Fast forward to the modern age and apparently the strlcpy and strlcat functions were formally accepted into GlibC 2.38 in 2023. This means anyone compiling on GCC/G++ will have native access to versions of these functions without having to fiddle with hand rolling them anymore.

With that in mind I'm going to update all of the codebases to switch them over to the native calls. Fortunately that should be as easy as globally replacing the function names with the native versions, so at least we did something right back in the day

If you're unaware of why this even matters, these functions are safer alternatives to older things like strncpy() and strncat() which don't have NULL terminations built in.

Heh, the payoff was immediate upon compiling AFKMud. It located 2 improper uses where our homebrew functions failed to identify buffer overruns during the compile.

I imagine it's likely to find similar in the rest of the bases.

BTW, looking at some things a bit more closely, I think that str_dup should get the same treatment since it's literally duplicating the purpose of the standard C strdup function.

strdup was apparently added to GlibC in the very early 2000's so it's definitely much more widespread as a result.