Date: Wed, 30 Apr 2003 21:03:09 +0300 From: Valentin Nechayev <netch@lucky.net> To: "Jacques A. Vidrine" <nectar@FreeBSD.org>, Paul Richards <paul@freebsd-services.com>, "W. Josephson" <cvs-D20030429@morphisms.net>, freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) Message-ID: <20030430180309.GB312@iv.nn.kiev.ua> In-Reply-To: <20030430164135.GB26508@madman.celabo.org> References: <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <Pine.GSO.4.10.10304300024280.1846-100000@pcnet1.pcnet.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -netch-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030430180309.GB312>