`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)

Valentin Nechayev netch at lucky.net
Wed Apr 30 11:04:47 PDT 2003

 Wed, Apr 30, 2003 at 11:41:35, nectar (Jacques A. Vidrine) wrote about "`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)": 

JAV>   Package X defines a function named `strlcpy', that works well for
JAV>   Package X and may or may not have any relationship to the `strlcpy'
JAV>   we all know and love from OpenBSD.

As already said in discussion in cvs-all@, this is why ports infrastructure
exists and has such features as now. You can't do full redesign of the whole
FreeBSD for any new application which potentially can run on it but has
its own and highly specific insects inside.
If application is inconsistent, as qpopper in this example, with current libc,
it's better to add something similar to `#define strlcpy qp_strlcpy' to its
headers, instead of making changes in libc. If there are a few hundreds of such
ports, your approach can be reasonable; but I can't see any reason making
things such way for the only one program, and bad program (qpopper's history
has too many exploits and its coding style is as ugly as seven sins together).
Adding one patch to port is better. Moreover, due to extremal uglyness
of qpopper, I think it anyway requires more steps (as static linking
with libparanoia, for instance).

JAV> Guess which scenario applied before my commit to make strlcpy/strlcat
JAV> weak references? which applies now? which would apply if we broke
JAV> strlcpy/strlcat into another library?

Is strlcpy defined with different interface and/or semantics in any
standard, including written, as Single Unix Spec, or real, as local tradition
or GNU software? I don't know such issues.

JAV> <sarcasm degree="a-bit-over-the-top">
JAV> Oh, of course.  I forgot that we only support applications written for
JAV> FreeBSD.  I thought we should be a decent platform for ISO C and POSIX
JAV> applications as well, but that is clearly foolishness.
JAV> </sarcasm>

ISO C and Posix doesn't know strlcpy(). ISO C defines, AFAIR, that all
function names matching /^str/ are reserved for future implementations,
but it's unreal to forecast seeing another strlcpy() in it.


More information about the freebsd-arch mailing list