From owner-freebsd-arch@FreeBSD.ORG Thu May 1 10:48:49 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 E57FF37B401; Thu, 1 May 2003 10:48:49 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F8343F3F; Thu, 1 May 2003 10:48:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003050117484700300fn002e>; Thu, 1 May 2003 17:48:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA73643; Thu, 1 May 2003 10:48:46 -0700 (PDT) Date: Thu, 1 May 2003 10:48:45 -0700 (PDT) From: Julian Elischer To: Paul Richards In-Reply-To: <20030501144600.GC1869@survey.codeburst.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: 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 17:48:50 -0000 On Thu, 1 May 2003, Paul Richards wrote: > 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. Exactly.. This is why we have ports It is also th king of thing that "configure" is supposed to fix.. The port should be altered to fix this and teh maintainers contected and told of the problem. I don't see why the libc needs to be changed at all.