From owner-freebsd-arch Sun Jan 21 14:40:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 83C4637B404; Sun, 21 Jan 2001 14:40:34 -0800 (PST) Received: from localhost (qieqtq@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0LMeSc20272; Sun, 21 Jan 2001 17:40:29 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101212240.f0LMeSc20272@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Eischen Cc: Warner Losh , "Jacques A. Vidrine" , arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: Message from Daniel Eischen of "Sun, 21 Jan 2001 16:44:38 EST." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 17:40:28 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Sun, 21 Jan 2001, Warner Losh wrote: > > In message Daniel Eischen writes: > > : Oops, sorry, I missed the second question. You need _foo to be > > : used within libc, so that when libc_r/libpthread is linked in, > > : it can provide a replacement function for it. We also need to > > : determine if the function is a cancellation point or not, so > > : if you just had foo and __sys_foo, libc_r/libpthread would have > > : no way of knowing if foo was called from within libc or from > > : the user application. The former is not a cancellation point, > > : while the latter is (if foo is read for example). > > > > I understand that. I guess my question is why name it _foo instead of > > __foo? I see the need for the tripartiteness, just not the need to > > call it _foo. > > I guess it doesn't matter to me wether it's _foo or __foo, but > we do have to use it within libc. We've already done the work > to use _foo in libc, so it's extra work to go back and use __foo. > I guess this gets back to the ANSI namespace issue. Our using > _foo in libc doesn't affect an applications namespace because > it's a weak definition; anything the user provides will override > it. But, that means that our internal use of _foo would then > call the user applications _foo. Yes, this is much too risky... if the two namespaces clearly stay away from eachother, then there's no worrying about this (unless you're a library writer who needs global __xxx symbols for some reason). > If it's OK for folks to see and use __foo in libc as opposed > to _foo, I can make that change. It's much too dangerous, I believe, to let libc escape out into the application's namespace much. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message