From owner-freebsd-arch@FreeBSD.ORG Tue May 6 13:16:55 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 76C7337B404 for ; Tue, 6 May 2003 13:16:55 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A99143F85 for ; Tue, 6 May 2003 13:16:53 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h56KGnxr086253; Tue, 6 May 2003 23:16:49 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h46KF3Id007855; Tue, 6 May 2003 23:15:03 +0300 (EEST) (envelope-from netch) Date: Tue, 6 May 2003 23:15:03 +0300 From: Valentin Nechayev To: Dag-Erling Smorgrav Message-ID: <20030506201503.GB313@iv.nn.kiev.ua> References: <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On Organization: Dark side of coredump 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 20:16:55 -0000 Tue, May 06, 2003 at 19:56:27, des (Dag-Erling Smorgrav) wrote about "Re: `Hiding' libc symbols": > - Applications which rely on overriding parts of the implementation > are non-conforming and cannot claim a "moral right" to do so. In > the few cases where applications have good and useful reasons for > overriding parts of the implementation, they can easily be modified > to cope with whatever techniques the implementation uses to avoid > namespace collisions. OK, this is possibly the main discussion stone. If application wants to override some library function, a mechanism to do it should exist (in any case application can get function address and install machine jump command to its, so it is not desirable to make unreasonable barriers;)) But this mechanism should be used explicitly, if policy requires. Thanks for good clarification. > The standard reserves a number of names and namespaces for the > implementation while others are reserved for the application. We (as Hmm, the first thing I want to see in C is namespaces, similar to C++ ones or better. > Namespaces > are a source code issue and cannot be handled anywhere but at the > source code level. I thought identically but hadn't enough words to say it. But what form of source code level support should be used? Some namespaces are defined using Posix|X/Open|SUS macros, but too few applications use it and properly define restriction macros in their sources; moreover, average open-source application is written with requesting of maximal namespace importing (as #define _GNU_SOURCE for GNU libc headers). C header file traditions adds its own hell: one can't include without strlcpy() not defining Posix restrictions, and there is no /usr/include/string/strlcpy.h which defines only it and size_t for its prototype;( Continuing this style, one can't separate declarations in subsets (Posix subset, SUS subset, BSD subset...) and the same problems will continue. (This wasn't positive position, but too skeptic...) -netch-