cvs commit: src/lib/libc/gen check_utility_compat.c confstr.c un-namespace.hgethostbydns.c getnameinfo.c hesiod.c ...

[Paul Richards]

On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote:
> 
> We have no business exporting symbols from libc that are not described
> by any standard.  We have no business assuming that if an application
> defines a function called `strlcpy' that it resembles, in intent or in
> actual implementation, our own strlcpy.

That's an orthogonal issue really, since libc is not a "pure"
implementation of the standard C library, it also includes a number of
extensions that have been bundled into our libc because it's sometimes
a convenient dumping ground.

Hiding functions that aren't meant to be exported would make sense,
but hiding functions that are intended to be exported but aren't
part of the standard is not so useful.

strlcpy is part of the "FreeBSD libc" since it's a documented interface
for application writers to use.

The alternative is to split out these functions and keep libc pure, and
then link them into our applications if we use them. This is an approach
other platforms have taken but one we've not gone down because of the
proliferation of libraries that then have to be included when writing
apps.

-- 
Paul Richards