Date: Thu, 1 May 2003 15:46:00 +0100 From: Paul Richards <paul@freebsd-services.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) Message-ID: <20030501144600.GC1869@survey.codeburst.net> In-Reply-To: <20030501143032.GA34163@madman.celabo.org> References: <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> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote: > On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote: > > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote: > > > [Trimmed cc:list; moving to freebsd-arch] > > > > > > > > > First, has something been broken by making strlcpy/strlcat into a weak > > > reference? > > > > Yes, deliberately overloading it from an application now no longer > > works. > > Give me a break. Good, it should not work by accident. An > application might define strlcpy for its own use, but we should NEVER > use the application's strlcpy. [1] An application doesn't have any business defining a strlcpy, since str* is reserved. The qpopper application is just broken and we shouldn't be "fixing" our libc to work around that. The only time you're likely to do something like this is if you're deliberately overriding the "official" implementation of these functions because you're instrumenting or something of a similar nature. > > What really concerns me though, is that behaviour is only defined > > for 2 functions. > > No, it is done for some 150+ functions. If the technique didn't have 150+? I must have missed that in the commit and subsequent discussion. > a certain distasteful side-effect when used en masse, I would push > for covering almost all of the other symbols libc exports. (If an > application defines `strcpy', should we use that from within libc?) > But until a better technique arrives, I am happy to apply it a little > less liberally. POLA suggests yes, since that's how it's always worked and there are a category of applications that rely on this behaviour (which would work on other platforms but not FreeBSD and for a reason that would be very hard to determine). Just because qpopper is broken doesn't mean that all applications should now be prohibited from exploiting this technique. > > The implementation of FreeBSD should be what's correct, we shouldn't > > fudge things to accomodate bad packages, fix the problem where the > > problem really exists. > > Obviously, I don't see it the same way you do. Calling the > application's strlcpy in order to implement some internal libc > function is not ``what's correct'', regardless of whether the > application is buggy or perfect. Hmm, perhaps a more correct implementation of our libc would not use the exported interface to implement the exported interface (thinking aloud). i.e. there'd be a _strlcpy that strlcpy was just a wrapper for and internally the _strlcpy would be used. -- Paul Richards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501144600.GC1869>