Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!uunet.UU.NET!sef
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-ID: <1991Jun16.050244.25708@uunet.uu.net>
Date: 16 Jun 91 02:27:52 GMT
References: <1991Jun12.043706.18456@uunet.uu.net> <1991Jun12.235808.20822@uunet.uu.net> <1991Jun15.175831.6319@uunet.uu.net>
Sender: usenet@uunet.uu.net (UseNet News)
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 27
Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix)
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

>All library routines are written to use the __ names; then, you have the
>linker accept an option that tells it to try to ignore the leading __ if
>there are unresolved externals.

Actually you don't need to hack the linker; you could supply a batch of
glue routines in the library like this:

	* select -- system call interface for use by applications
	*		(C library must invoke __select instead of select)
		global	__select
		entry	select
	select	jmp	__select

That way both applications that supply their own select() and those that
expect select() to be linked from the system library are happy.

The only reasons I can think of for hacking the linker instead are
	(a) debugging looks neater
	(b) a tiny amount of time is saved by not branching
	(c) C library maintenance is slightly easier


[ This covers functions, but not data.  Such as _iob -- mod ]

Volume-Number: Volume 24, Number 10