From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:51:54 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 0300937B404 for ; Tue, 6 May 2003 12:51:54 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3B0043F3F for ; Tue, 6 May 2003 12:51:52 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h46JpprO060241; Tue, 6 May 2003 23:51:51 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h46JppiC060240; Tue, 6 May 2003 23:51:51 +0400 (MSD) Date: Tue, 6 May 2003 23:51:51 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030506195151.GA60115@nagual.pp.ru> References: <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> <20030506182756.GA57720@nagual.pp.ru> <20030506190747.GA59160@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols 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: Tue, 06 May 2003 19:51:54 -0000 On Tue, May 06, 2003 at 21:39:51 +0200, Dag-Erling Smorgrav wrote: > No. It will lead to surprising results if the file that includes > really does use sin(), but if it doesn't there is no reason > why the other file can not define an external symbol named sin because > sin is in the application namespace in that file. If some file includes even not using any functions from it, it declares namespace visibility for whole application. > > About c), at this moment we discuss functions namespace only, i.e. linker > > "T" class. > > So you admit that your solution is incomplete? In that case, why do > you insist that it is superior to Jacques Vidrine's solution, which > addresses all cases without requiring us take the linker off the > vendor branch and make it unusable for non-hosted applications? It is incomplete in the same way as Jacques one since we both discuss only functions so far. The difference is that my approach move us towards standards conformance while Jacques one to opposite direction.