From owner-freebsd-arch@FreeBSD.ORG Thu May 1 07:46:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B501737B401; Thu, 1 May 2003 07:46:02 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA63643F3F; Thu, 1 May 2003 07:46:01 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id B72A51B214; Thu, 1 May 2003 15:46:00 +0100 (BST) Date: Thu, 1 May 2003 15:46:00 +0100 From: Paul Richards To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030501144600.GC1869@survey.codeburst.net> References: <20030430002014.GA1190@dragon.nuxi.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501143032.GA34163@madman.celabo.org> User-Agent: Mutt/1.4.1i Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:46:03 -0000 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