From owner-freebsd-hackers Fri Feb 27 06:17:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25515 for freebsd-hackers-outgoing; Fri, 27 Feb 1998 06:17:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25506 for ; Fri, 27 Feb 1998 06:17:37 -0800 (PST) (envelope-from lada@ws2301.gud.siemens.at) Received: from ws2301.gud.siemens.co.at (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id PAA28839; Fri, 27 Feb 1998 15:17:04 +0100 (MET) Received: from ws6423.gud.siemens.at (ws6423-f.gud.siemens.co.at) by ws2301.gud.siemens.co.at with ESMTP (1.40.112.8/16.2) id AA245268900; Fri, 27 Feb 1998 15:15:01 +0100 Received: by ws6423.gud.siemens.at (SMI-8.6/SMI-SVR4) id PAA25144; Fri, 27 Feb 1998 15:15:35 +0100 Date: Fri, 27 Feb 1998 15:15:35 +0100 From: lada@ws2301.gud.siemens.at (marino.ladavac@siemens.at) Message-Id: <199802271415.PAA25144@ws6423.gud.siemens.at> To: hackers@FreeBSD.ORG, kaleb@opengroup.org Subject: Re: symbols in libc_r not in libc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: 0nZvlOgXKzpc4bpETYxnOw== Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 27 14:41:50 MET 1998 > Date: Fri, 27 Feb 1998 13:38:59 -0500 > From: "Kaleb S. KEITHLEY" > Mime-Version: 1.0 > To: hackers@FreeBSD.ORG > Subject: Re: symbols in libc_r not in libc > Content-Transfer-Encoding: 7bit > X-Loop: FreeBSD.ORG > > > Well, just that Xlib isn't in the business of providing libc functions > or putting a band-aid over a broken libc. > > The weak __error() function belongs in libc. Well, I am obviously of a different opinion--I'll try to give you my rationale for it. libc exports a well-known interface to its clients. errno is one of these interfaces, and if the clients want to use just libc, this is all they get. Now, you are building a client (Xlib) which should be usable both as a reentrant and non-reentrant library. There is a slight dichotomy here. You really need an interface the libc does not need to provide (nor is required to do so). Since your Xlib in this particular case is misusing the libc, it has to live with the interfaces that the libc provides. Therefore, it needs to provide its own interfaces made from the building blocks provided by libc. The problem that we both have with this is that your Xlib is a performance hack. The pure solution would require the existence of Xlib and Xlib_r. Let me state immediately that I am all for such an Xlib--having two of them would be one too many. I hope you understand my view. I'm pretty sure I did not miss anything this time :) /Marino > > -- > Kaleb S. KEITHLEY > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message