[Bug c++/46513] Request: Warning for use of unsafe string handling functions

noloader at gmail dot com gcc-bugzilla@gcc.gnu.org
Wed Nov 17 03:21:00 GMT 2010


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.



More information about the Gcc-bugs mailing list