Date: Tue, 06 May 2003 19:56:27 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: netch@lucky.net Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols Message-ID: <xzpllxkez78.fsf@flood.ping.uio.no> In-Reply-To: <20030506170823.GI83663@lucky.net> (Valentin Nechayev's message of "Tue, 6 May 2003 20:08:23 %2B0300") References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Valentin Nechayev <netch@lucky.net> writes: > Tue, May 06, 2003 at 04:23:48, des wrote about "Re: `Hiding' libc symbols": > > And I think you just don't understand the issue, and should leave it > > to those who do while you take time off to read ISO/IEC 9899:1990. > Can you please say some extraction from it for those poor guys not having > got this standard? The standard reserves a number of names and namespaces for the implementation while others are reserved for the application. We (as an implementation vendor) regularly trespass into the application namespace, and applications regularly trespass into the implementation namespace. Those are facts of life. There are a couple of things we need to take care of to avoid serious breakage: - The implementation (libc) must yield to the application in areas where it trespasses into the application namespace. The linker handles that since libc is always last on the linker command line. - To the extent that libc relies on symbols in the application namespace which it defines itself, it must behave as if it didn't (because those names belong to the application) meaning that it must ensure that it uses its own versions of those symbols and not the application's. This is handled partly by namespace.h. - The implementation must also guard itself against applications which incorrectly define names in the implementation namespace, because there are just too many of them to realistically expect fixing them all. Moreover, I strongly believe that it is our task as implementation vendors to ensure that our implementation is as robust as possible in the face of non-conforming applications. - One important caveat is that (most) reserved names that do not begin with an underscore are reserved only when the header in which the standard requires them to be defined is included. This is one of the reasons why I advocate building world with -fno-builtin; gcc incorrectly reserves names for builtin functions even when the standard mandates that these names are in the application namespace. For instance, math functions such as sin(3) and cos(3) should not be defined unless <math.h> is included, but gcc always defines them, thus breaking applications which use these names themselves (sin is a popular name for sockaddr_in structs) (another reason for using -fno-builtin is that gcc's builtins hide bugs, especially those related to missing headers) - If you stayed awake through the previous paragraph you should by now have concluded that it simply is not possible for the linker to enforce namespaces like Andrey wants it to, because a) the linker can't know what headers were included; b) the exact set of reserved names can vary from compilation unit to compilation unit within the same application and c) namespace issues affect portions of the code which are outside the linker's purview (such as the names of function arguments and static or automatic variables). Namespaces are a source code issue and cannot be handled anywhere but at the source code level. - 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. In the case of ElectricFence, this means adding _malloc, _calloc etc. as aliases for malloc, calloc etc.; boehm-gc is not an issue because we don't configure it with --enable-redirect-malloc. DES -- Dag-Erling Smorgrav - des@ofug.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpllxkez78.fsf>