http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513
--- Comment #3 from Jeffrey Walton <noloader at gmail dot com> 2010-11-17 02:04:14 UTC --- (In reply to comment #1) > The maintainers of GNU libc, the C and C++ committees and the POSIX working > group have not seen fit to include those functions, and they're not available > on my GNU/Linux box. Indeed. Below is from "Secure Portability" by Damien Miller (http://www.openbsd.org/papers/portability.pdf). I know "finding the replacement" is not a GCC issue, but perhaps folks who need to the *nix safe string gear can use TR24731-2 (not TR24731-1), which is POSIX and includes strl* and friends. And to reiterate: the warning would be useful. Miller states [in 1995] over 100 projects are *NOT* using strcpy and friends. So there are at least 100 projects (plus me) who would likely use the switch ;). The number would only grow as other security minded folks became aware of the GCC functionality. Jeff The strlcpy and strlcat API properly check the target buffer’s bounds, nul-terminate in all cases and return the length of the source string, allowing detection of truncation. This API has been adopted by most modern operating systems and many standalone software packages, including OpenBSD (where it originated), Sun Solaris, FreeBSD, NetBSD, the Linux kernel, rsync and the GNOME project. The notable exception is the GNU standard C library, glibc [12], whose maintainer steadfastly refuses to include these improved APIs, labelling them “horribly inefficient BSD crap” [4], despite prior evidence that they are faster is most cases than the APIs they replace [13]. As a result, over 100 of the software packages present in the OpenBSD ports tree maintain their own strlcpy and/or strlcat replacements or equivalent APIs - not an ideal state of affairs.
