From owner-freebsd-arch@FreeBSD.ORG  Tue May  6 13:16:55 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <netch@lucky.net>
To: Dag-Erling Smorgrav <des@ofug.org>
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> <xzpk7d53zu5.fsf@flood.ping.uio.no>
	<20030505205051.GA40572@nagual.pp.ru>
	<20030505231135.GA21953@madman.celabo.org>
	<20030505231837.GA44533@nagual.pp.ru> <xzpy91k3j9n.fsf@flood.ping.uio.no>
	<20030506170823.GI83663@lucky.net> <xzpllxkez78.fsf@flood.ping.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xzpllxkez78.fsf@flood.ping.uio.no>
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
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=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

<offtopic> Hmm, the first thing I want to see in C is namespaces, similar
to C++ ones or better.</offtopic>

>    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 <string.h>
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-