Date: Tue, 6 May 2003 23:15:03 +0300 From: Valentin Nechayev <netch@lucky.net> To: Dag-Erling Smorgrav <des@ofug.org> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols Message-ID: <20030506201503.GB313@iv.nn.kiev.ua> In-Reply-To: <xzpllxkez78.fsf@flood.ping.uio.no> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030506201503.GB313>